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(57) Abstract: The invention relates to a method for implementing an op- 
erating and observation system for field devices (FG1-FGN). A server de- 
vice (HS1-HSN) is provided in each field device and the field devices are 
connected to a proxy server device (1). Said proxy server device is con- 
nected to a user device (Nl-NN) on which a browser device is installed. 
The proxy server device interrogates the field devices in order to automat- 
ically identify the field devices which are connected to the proxy server 
device, and allocates a network address to each field device. A basic in- 
formation message is produced by the proxy server device, said informa- 
tion message comprising specific electronic information about each field 
device, based on the results of the interrogation thereof. The respective 
electronic information comprises link information concerning the respec- 
tive server device of each field device, such that after the basic informa- 
tion message has been transmitted to the user device, respective device 
information messages are emitted in a graphical manner, by means of the 
browser device, for the observation/operation of the field devices. Said 
device information messages can be requested from the respective server 
devices of the field devices. 

(57) Zusammenfassung: Die Erfindung betrifft ein Verfahren zur Inbe- 
triebnahme einesBedien- und Beobachtungssy stems fur Feldgerate (FG1- 
FGN), wobei in den Feldgeraten jeweils eine Servereinrichtung (HS1- 
HSN) ausgebildet ist und die Feldgerate an eine Proxy-Servereirrrichtung 
(1) angeschJossen sind und wobei die Proxy-Servereinrichtung mit einer 
Nutzereinrichtung (Nl-NN) verbunden ist, auf welcher eine Browser-Ein- 
richtung installiert ist. Es wird durch die Proxy-Servereinrichtung eine 
Abfrage der Feldgerate zum automatischen Erkennen der an die Proxy- 
Servereinrichtung angeschlossenen Feldgerate ausgefuhrt und eine jewei- 
ligen Netzwerkadresse fur die Feldgerate vergeben. Eine Basisinforma- 
tion wird durch die Proxy-Servereinrichtung erzeugt, wobei die Basisin- 
formation in Abhangigkeit von der Abfrage der Feldgerate jeweilige elek- 
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Informationen uber die Feldgerate umfasst und wobei die jeweiligen elektronischen Informationen eine Link-Information auf die 
jeweilige Servereinrichtung der Feldgerate so umfassen, dass nach einem Ubermitteln der Basisinformauon an die Nutzereinrichtung 
mit Hilfe der Browser-Einrichtung jeweilige Gerateinformationen zum Beoijachten/Bedienen der Feldgerate grafisch ausgegeben 
werden, die von der jeweiligen Servereinrichtung der Feldgerate abrufbar sirid. 
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Beschreibung 

Verfahren zur Inbetriebnahme eines Beciien- und 
Beobachtungssystems von Feldgeraten 

5 

Die Erfindung liegt auf dem Gebiet des f erngesteuerten 
Betreibens von Feldgeraten, insbesondere zum Zweck des Beo- 
bachtens und Bedienens von Feldgeraten, beispielsweise in e- 
nergietechnischen Anlagen. 

10 

Feldgerate werden im Rahraen der Automatisierung von verschie- 
densten technischen Prozessen genutzt, beispielsweise zum U- 
berwachen eines Productions- bzw. Herstellungsprozesses oder 
eines Verarbeitungsprozesses . Bei den Feldgeraten kann es 
15 sich urn die Produktionsanlagen selbst oder urn Gerate zum U- 
berwachen, vorzugsweise zum Steuern und/oder zum Regeln in 
Abhangigkeit von erf ass ten Felddaten, der eingesetzten tech- 
nischen Produktionsmittel bzw. -anlagen handeln. 

2 0 Beim Bedienen der Feldgerate im Einsatz konnen grundsatzlich 
zwei Arten der Bedienung unterschieden werden. Einerseits 
konnen die Feldgerate vor Ort mittels Betatigung der vorgese- 
hen Bedienelemente betatigt werden. Hierbei muss sich der Be- 
diener am Feldgerat bef inden oder zur entsprechenden Anlage 

25 fahren. Andererseits gehort die Fernbedienung von Feldgera- 
ten aus Uberwachungs-' und Wartungszentralen zum bekannten 
Stand der Technik. Standard- Terminalprogramm, die hierbei 
zur Bedienung der Feldgerate eingesetzt werden, stellen dem 
Bediener nur einen sehr geringen. Komf ort zur Verfugung und 

30 gestatten in der Regel nur einfache Bedienhandlungen. Insbe- 
sondere grafisch aufbereitete Inf ormationen, beispielsweise 
Messdaten, lassen sich nicht fur den Bediener darstellen. 
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Es wurden deshalb komplexe Bedienprogramme fur die Fernbedie- 
nung der Feldgerate entwickelt. Solche komplexen Bedienpro- 
gramme mussen auf dem jeweiligen Feldgerat installiert werden 
land belegen so Speicherbereiche, die fur die Gerateanwendung 
nicht mehr zur Verfiigung stehen. Daruber hinaus benotigt je- 
der Bediener das fur das jeweilige Feldgerat erf orderliche 
Bedienprogramm. Bei Feldgeraten ve^schiedener Hersteller o- 

i 

der Feldgeraten des gleichen Herstellers mit unterschiedli- 
chen Ausgabestanden konnen relativ schnell eine Vielzahl von 
Programmen oder Programmversionen benotigt werden. 

In Verbindung mit den bekannten Bedienverf ahren entsteht ein 
erheblicher Auf wand bei der Parametrierung der Feldgerate, 
die vor der Inbetriebnahme der bekannten Bedien- 
/Beobachtungssysteme notwendig ist. 

Feldgerate werden ublicher Weise mit einer Standardparameter- 
einstellung ausgelief ert . Diese Standardparameter konnen von 
einem Nutzer/Bediener vor Ort am Gerat verandert werden, wo- 
bei schon bei einer Veranderung von wenigen Parametern auf- 
grund der oftmals eingeschrankten Anzeigemoglichkeiten am Ge- 
rat der Uberblick liber Standardparameter bzw. geanderte Para- 
meter verloren geht . Komplexe PC-Bedienprogramme, die eine 
ubersichtliche, grafische Aufbereitung der Parame- 
ter/Parametergruppen sowie eine Speicherung/Archivierung der 
Parameter bieten, weisen den Nachteil auf, dass durch Gerate- 
und/oder Programmversionen schnell der Uberblick verloren 
geht. Dieses Problem verstarkt sich besonders dann, wenn ein 
Anwender verschiedene derartige Gerate im Einsatz hat, die 
jeweils andere Bedienprogramme oder andere Versionen des 
gleichen Bedienprogramms erfordern. 
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Aufgabe der Erfindung ist es, eine verbesserte Moglichkeit 
zur Vorbereitung einer Inbetriebnahme bei der Fernbedienung 
von Feldgeraten zu schaffen, die fur verschiedene Feldgerate- 
typen flexibel einsetzbar ist und bei der mit der Inbetrieb- 
5 nahme verbundene Aufwand vermindert ist. 

Die Aufgabe wird erf indungsgemaS durch das Verfahren nach An- 
spruch 1 gelost. 

10 Mit der Erfindung wird ein Verfahren vorgeschlagen, welches 
die Inbetriebsetzung eines Bedien- und Beobachtungssystems 
ohne vorherige Parametrierung der Systemkomponenten gestat- 
tet. Die Proxy- Server einrichtung erkennt die angeschlossenen 
Feldgerate und deren Alarmstatus . Diese Inf ormationen werden 

15 auf einer vorzugsweise dynamisch erzeugten Homepage auf der 

Nutzereinrichtung mittels eines Links auf eine Seite der Ser- 
ver einrichtung des jeweiligen Feldgerate verof f entlicht . Die 
Servereinrichtung der angeschlossenen Feldgerate beinhalten 
jeweils die speziell auf das jeweilige Feldgerat zugeschnit- 

2 0 tenen Inf ormationen (HTML- Seiten/ Java-Archive) fur die Bedie- 

nung des Feldgerats. Hierdurch reduziert sich die Paramet- 
rierung des Bedien- und Beobachtungssystems im wesentlichen 
auf die Vergabe der Netzwerkadressen fur die angeschlossenen 
Feldgerate . 

25 

Die mittels der Proxy- Servereinrichtung in Abhangigkeit von 
der Abfrage erzeugte Homepage wird in der (den) Nutzereinrich- 
tung (en) mit Hilfe der Browser-Einrichtung ausgegeben. 

3 0 Bei einer vorteilhaf ten Weiterbildung der Erfindung ist vor- 

gesehen, dass die Basisinf ormationen in einer Speicherein- 
richtung der Proxy-Servereinrichtung gespeichert wird, wo- 
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durch die Basisinformationen fur den anschlieSenden Betrieb 
des Bedien- und Beobachtungs systems gesichert sind. 

Eine vorteilhafte Ausgestaltung der Erfindung sieht vor, dass 
die Basisinformationen eine jeweilige Alarmstatusinf ormation 
fur die Feldgerate umfassen. Diese Alarmstatusinf ormation 
gewahrleistet einen schnellen Uberblick liber den Status aller 
Gerate einer Anlage, ohne alle verfugbaren Inf ormationen 
(Meldungen, Storungen, Messwerte. . .) anzuzeigen. Die Alarm- 
statusinf ormation wird vorzugsweise durch ODER-Verkniipf ung 
der fur die geeignet f estzulegenden jstati relevanten Informa- 
tionen gebildet (z.B. Ampel : rot — Storsammelmeldung: Hard- 
warefehler, Betriebsstorung; gelb - Warnsammelmeldung; grun - 
keine Warnungen/Storungen) . Ein Anwender kann nun mit einem 
Blick auf die Statusinf ormation der Gerate erkennen, ob er 
Detailinformationen von den Geraten benotigt und muss diese 
Detailinf ormationen nur noch auswerten, wenn die Alarmstatus- 
inf ormation eine entsprechende Anzeige liefert. 

Bei einer bevorzugten Fortbildung der Erfindung kann vorgese- 
hen sein, dass die Basisinformationen elektronische Daten zum 
automatischen Erzeugen eines grafisch ausgebbaren Bedienbaums 
mittels der Browsereinrichtung naeh dem Ubermitteln der Ba- 
sisinf ormation von der Proxy-Servereinrichtung an die Nutzer- 
einrichtung umfassen, wodurch eine einfache und fur den Be- 
diener leicht zu uberblickende Form der Darstellung der tech- 
nischen Ebenen in den Feldgeraten sowie zwischen den Feldge- 
raten geschaf f en ist . 

Eine zweckmaEige Weiterbildung der Erfindung sieht vor, dass 
die Abfrage der Feldgerate durch die Proxy- Servereinrichtung 
zum automatischen Erkennen der an die Proxy-Servereinrichtung 
angeschlossenen Feldgerate mit Hilfe einer ^broadcast «- 
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Anfrage ausgefuhrt wird. Bei einer „broadcast w - 
Konf igurationsabf rage wird in alien Feldgeraten des gesamten 
Ne t z werks egment e s der in den Feldgeraten integrierte Dienst 
zur Abfrage der Geratekonf iguration aktiviert. Daraufhin sen- 
den alle Feldgerate in diesem Segment ihre Konf igurationsda- 
ten an den Ausloser der Konf igurationsabf rage . 

Das Verfahren kann vorteilhaft zum Uberwachen/Bedienen ener- 
-gietechnischer Anlagen verwendet werden, die haufig ortlich 
verstreut angeordnet sind. 

Das Verfahren und/oder die Vorrichtung konnen vorteilhaft zum 
Uberwachen energietechnischer Anlagen verwendet werden. 

Die Erfindung wird im folgenden anhand von Ausf lihrungsbei- 

spielen unter Bezugnahme auf eine Zeichnung naher erlautert. 

\ 

Hierbei zeigen : 

Figur 1 eine schematische Darstellung mit einem Geratenetzwerk 
und einem Firmen- Intranet , die uber einen Proxyserver 
verbunden sind; 

Figur 2 eine Oberf lachengestaltung einer Browser- 

Einrichtung 1 mit grafischen Darstellungen fur mehre- 
re Feldgerate; 

Figur 3 eine andere Oberf lachengestaltung der Browser- 

Einrichtung mit einer grafischen Darstellung einer 
Frontansicht eines Feldgerats; 

Figur 4 eine schematische Darstellung eines Feldgerats und 
eines Nutzer-Personalcomputers ; 
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Figur 5 ein Ablauf diagramm fur ein Heruriterladen von HTML- 
Seiten im Rahmen eines Beolpachtungs - und Bediensys- 
tems ; 

5 Figur 6 ein Blockdiagramm zum Erlautern eines RPC-Aufrufs; 

Figur 7 eine Darstellung der Anordnung mit dem Geratenetz- 
werk und dem Firmen- Intranet nach Figur 1, wobei 
einzelne Elemente des Proxyservers schematisch ge- 
10 zeigt sind; 

Figur 8 eine schematische Blockdarstellung des Proxyser- 
vers ; 

15 Figur 9 eine schematische Darstellung zur Erlauterung einer 
Cl i ent / Server - Int erakt ion ; 

Figur 10 eine schematische Darstellung zur Erlauterung einer 
Gerateerkennung in einer Mdster/Slave-Anordnung; 



20 



25 



Figur 11 ein Nassi-Sneider-Diagramm; 

Figur 12 eine schematische Baumdarstellung eines Verfahrens 
zur Gerateerkennung; 

Figur 13 eine schematische Darstellung einer Master/Slave- 
Anordnung zur Erlauterung einer Konf igurationsab- 
frage; 



3 0 Figur 14 ein schematische Blockdarstellung einer Geratver- 
waltung im Proxyserver; 
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Figur 15 eine schematische Blockdarstellung zur Erlauterung 
der f unktionellen Einbindung eines XSL-Parsers in 
dem Proxyserver (XSL - „ Extended Stylesheet Langua- 
ge u ) ; und 

Figur 16 eine schematische Blockdarstellung zur Erlauterung 
eines XSLT-Prozessors (XSLT - „ Extended Stylesheet 
Language Transformations") . 

Im folgenden wird ein in Verbindung mit Feldgeraten nutzbares 
sogenanntes Beobachtungs- und Bediensystem (BuB-System) be- 
schrieben. 

Figur 1 zeigt eine schematische Architektur von zwei Netzwer- 
ken, ein Geratenetzwerk mit mehreren Feldgeraten FG1...FGN 
und ein Firmen- Intranet mit mehreren Nut zereinrichtungen 
Nl. . .NN, vorzugsweise Personalcomputer (PC) . . Das Geratenetz- 
werk und das Firmen- Intranet sind uber einen Proxyserver 1 
verbunden. Der Proxyserver 1 ist Bestandteil des Beobach- 
tungs- und Bediensystems und dient als ein Gateway zwischen 
dem Geratenetzwerk und dem Firmen- Intranet . Mit Hilfe des 
BuB- Systems werden einerseits Inf ormationen, beispielsweise 
Mess- und/oder Zustandsdaten, von den Feldgeraten FG1...FGN 
erfasst und an die Nut zereinrichtungen N1...NN iibermittelt, 
urn einen Benutzer der Nutzereinrichtungen N1...NN uber den 
Betriebszustand der Feldgerate FG1...FGN zu inf ormieren . An- 
dererseits dient das BuB-Systems zum Erfassen von Bedien- 
bzw. Steuereingaben des Benutzers mit Hilfe der Nutzerein- 
richtungen Nl . . . NN und zum Umsetzen der Eingaben des Benut- 
zers in den Feldgeraten FG1...FGN. Bei den Feldgeraten 
FG1...FGN kann es sich urn beliebige Gerate zum Beobachten, 
zum Messen, zum Steuern und/oder zum Regeln verschiedenster 
physikalischer Grofien in unterschiedlichen technischen Pro- 
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zessen handeln, beispielsweise zum Uberwachen und/oder Steu- 
ern energietechnischer Anlagen, beispielsweise eines Umspann- 
werks . 

Das Geratenetzwerk umfasst einzelne PPP-Verbindungen 2 (PPP - 
„ Point to Point Protocol w ) , die liber, einen Sternkoppler 3 mit 
dem Proxyserver 1 verbindbar sind, .oder ein separates Ether- 
net-Segment. Der Proxyserver 1 stellt eine eigene Homepage 
in Form von HTML-Daten (HTML - „HyperText Markup Language u ) 
zur Verfugung, die eine Ubersicht uber die in dem Geratenetz- 
werk erreichbaren Feldgerate FG1...FGN zeigt (vgl . Figur 2); 
die Homepage kann mit Hilfe eines Standard-Browsers in den 
Nutzereinrichtungen N1...NN dargestellt werden. 

Gemafi Figur 1 sind die Feldgerate FG1...FGN nur mit dem 
Sternkoppler 3 und einem daran angeschlossenen Modem 4 aus- 
gestattet. In diesem Fall sind die Feldgerate FG1...FGN uber 
eine asynchrone serielle Schnittstelle direkt uber den Stern- 
koppler 3 mit dem Modem 4 verbunden. Es sind verschiedene 
Formen der Ankopplung uber aktive und passive Sternkoppler 
moglich. Als Protokoll fur den Zugriff auf die Feldgerate 
FG1...FGN wird ein IP-Protokoll (IP - ^Internet Protocol^) 
uber eine PPP-Linkschicht verwendet. 

Wenn die Feldgerate FG1...FGN mit einem Ethernet -Anschluss 
ausgestattet sind, sind die Ethernet -Anschlusse mit einem 
Switch oder einem Hub verbunden. Besitzt dieser Switch oder 
dieser Hub neben Ethernet -Ports auch einen PPP-Port, dann 
spricht man von einem Router. Dieser PPP-Port kann dann eben- 
falls direkt mit dem Modem 4 verbunden werden. 

Im Firmen- Intranet haben die an das lokale Netz angeschlosse- 
nen Nutzereinrichtungen Nl . . . NN Zugang zu einem Modem 5, wel- 
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ches uber ein Telekommunikationsnetz 6, beispielsweise ein 
Telefonnetz auf Basis eines ISDN- oder eines Mobilfunk- 
Netzes, mit dem Modem 4 des Geratenetzwerk verbindbar ist. 
Wird in den Nutzereinrichtungen N1...NN jeweils eine DFU- 
5 Verbindung (DFU - Datenf ermibertragung) eingerichtet , kann 
von den Nutzereinrichtungen N1...NN aus jeweils ein Zugriff 
auf die Feldgerate FG1 . . .FGN erf olgen. Wird nun der Proxy - 
~ server 1 von den Nutzereinrichtungen N1...NN angesprochen, 
■> kann von jeder der an das Firmen- Intranet angeschlossenen 

10 Nutzereinrichtungen N1...NN auf die Feldgerate FG1...FGN zum 
Beobachten und Bedienen zugegriffen werden. Der Proxyserver 
1 „spiegelt u alle Feldgerate FG1...FGN, d.h. Inf ormationen 
uber die Feldgerate FG1...FGN, ins Firmen- Intranet . Dazu 
werden vom Proxyserver 1 die folgenden Protokolle verarbei- 

15 tet: HTTP- Pro tokoll (HTTP - „Hypertext Transfer Protocol w und 
RPC-Protokoll (RPC - „Remote Procedure Call") . Das HTTP- 
Protokoll dient zur Ubertragung statischer Daten. Hierbei 
handelt es sich urn Daten, die nur einmalig an den Proxyserver 
1 ubertragen werden und anschlieEend dort in einem Dateispei- 

2 0 cher fur spatere Abrufe durch die Nutzereinrichtungen N1...NN 

abgelegt werden. Das RPC-Protokoll, welches ebenfalls ein 
IP-basiertes Protokoll ist, wird zum Ubertragen dynamischer 
Daten genutzt. Bei den dynamischen Daten handelt es sich 
insbesondere urn in ddn Feldgeraten FG1 . . • FGN erfasste Mess- 
25 werte und/oder Ereignislisten, betreffend Inf ormationen uber 
Ereignisse in den Feldgeraten FG1 • . . FGN - 

Das HTTP- Protokoll gestattet den Nutzereinrichtungen Nl . . . NN 
den Zugriff auf die Feldgerate FG1...FGN. Bei einem Zugriff 

3 0 im Rahmen des BuB-Systems werden zunachst mittels der Anwahl 

der zugehorigen IP-Adresse des zu bedienenden/beobachtenden 
Feldgerats HTMIi-Daten von dem Feldgerat an die in diesem An- 
wendungsfall genutzte Nutzereinrichtung ubermittelt, wobei 
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die HTML-Daten Daten umfassen, mit deren Hilfe in der Brow- 
ser-Einrichtung der abrufenden Nutzereinrichtung eine Dar- 
stellung des Feldgerats erzeugt werden kann, wie dies bei- 
spielhaft in Figur .3 dargestellt ist. Der Abruf der HTML- 
5 Daten zum Erzeugen der Darstellung gema£ Figur 3 kann mit 
Hilfe einer Auswahl eines der in Figur 2 in der Ubersicht 
dargestellten Feldgerate durch den Benutzer ausgelost werden, 
beispielsweise mittels der Betatigung einer Maus oder einer 
Tastatur der Nutzereinrichtung . 

10 

GemaS Figur 3 sind auf der Oberflache 2 0 der Browser- 
Einrichtung die f olgenden Inf ormationen dargestellt (vgl . 
linke Seite in Figur 3): Feldgeratef amilie (z.B. SIPROTEC4 ) , 
Feldgerateart und Feldgeratetyp 21, ein Bedienbaum 22, die 

15 Version des BuB-Tools 23 (Version und Datum) und Angaben zur 
Verbindung 24 mit dem Feldgerat (MLFB - „Maschinenlesbare 
Fabrikationsbezeichnung" , BF-Nummer, Verbindungs status und 
IP-Adresse) . Auf der Oberflache ist weiterhin die einem Link 
bzw. Zweig im Bedienbaum 22 zugeordnete HTML-Seite 25 ange- 

20 zeigt . In Abhangigkeit von dem im Bedienbaum 22 ausgewahlten 
Link wird die zugehorige HTML- Seite 25 auf der Oberflache 2 0 
der Browser-Einrichtung dargestellt. 

Die in den Feldgeraten FG1 . • . FGN abgelegten HTML-Seiten, d.h. 

25 auch die zur Erzeugung der in Figur 3 gezeigten Darstellung 
genutzte HTML-Seite 25, konnen Java-Code umfassen, der die 
Browser-Einrichtung der jeweiligen Nutzereinrichtung N1...NN 
dazu veranlasst, parallel zu der bestehenden HTTP-Verbindung 
zur Darstellung der aus den Feldgeraten FG1 . . . FGN geladenen 

3 0 HTIVIL-Seite eine weitere Verbindung mit den Feldgeraten 

FG1...FGN aufzubauen. Diese zweite Verbindung benutzt das 
RPC-Protokoll, um dynamische Daten, wie Ereignislisten oder 
Messwerte, aus den Feldgeraten FG1...FGN besonders schnell 
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und ef fektiv fur die Darstellung in den Nutzereinrichtungen 
N1...NN innerhalb einer angewahlten HTML-Seite, beispielswei- 
se der in Figur 3 gezeigten HTML-Seite 25, zu ubertragen. 

5 Inf ormationsabruf aus den Feldgeraten 

Figur 4 zeigt eine schematische -Darstellung zur naheren Er- 
lauterung des Abrufens der Inf ormationen im Rahmen des BuB- 
Systems von den Feldgeraten FG1...FGN in die Nutzereinrich- 
10 tungen Nl . . .NN. 

GemaS Figur 4 ist auf einem Nutzer- Personal computer 30, der 
eine beispielhaf te Ausbildung der Nutzereinrichtungen N1...NN 
darstellt, eine Browser-Einrichtung 31 installiert. Der Nut- 

15 zer-Personalcomputer 3 0 ist uber ein IP-Netzwerk 32, welches 
den Proxyserver 1, den Sternkoppler 3, das Modem 4, das Modem 
5 sowie das Telekommunikationsnetzwerk 6 umfassen kann, mit 
einem Feldgerat 33 verbunden. Das Feldgerat 33 weist einen 
HTTP-Server 34 auf. In dem Feldgerat 33 sind HTML-Seiten 35 

20 gespeichert, die fur dieses Feldgerat 33 spezifische Inf orma- 
tionen umfassen. Die HTML-Seiten 3 5 enthalten beispielsweise 
eine HTML-Darstellung der Frontansicht des Feldgerats 33. 
Die HTML-Seiten 35 sind speziell auf das Feldgerat 33 abge- 
stimmt und konnen mittels eines HTTP-Herunterladens vom HTTP- 

25 Server 34 des Feldgerats 33 durch den Nutzer-Personalcomputer 
3 0 abgerufen werden. Die Anforderung der HTML-Seiten 35 aus 
dem Feldgerat 33 kann mittels der Eingabe einer URL (URL - 
„ Uniform Resource Locator u ) in der Brows er-Einrichtung 31 o- 
der mittels der Referenz aus einer anderen HTML-Seite heraus 

30 („Link u ) ausgelost werden. Neben den HTML-Seiten 35 werden 

vom Feldgerat 33 eine Reihe von Rohdaten 3 6 (Messwerte, Para- 
meter, etc.) in Form von Dateien bereitgestellt . In den 
HTML-Seiten 3 5 befinden sich Referenzen auf die im Feldgerat 
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33 verfugbaren Rohdaten 36. Sollen die Rohdaten 36 ausgewer- 
tet Oder in sonstiger Weise verandert werden, wird ein Pro- 
gramm bendtigt, welches nach bestimmten Algorithmen hochwer- 
tige Datenformate erzeugen kann. Diese Datenf ormate konnen 
5 dann von dem Programm beispielsweise zur Bildschirmanzeige in 
Verbindung mit Analysemoglichkeiten verwendet werden. Die 
hierfur notwendige Rechenleistung steht in dem Feldgerat 33 
in der Regel nicht zur Verfugung. Mit Hilfe der Browser- 
Einrichtung 31 besteht fur den Anwender die Moglichkeit, un- 
10 ter Nutzung des IP-Netzwerks 32 ubeir Kommunikationsverbindun- 
gen (Modem, Telef onnetze, LAN - „Local Area Network", WAN - 
„Wide Area Network") auf die HTML-Seiten 35 aus dem Feldgerat 
33 und damit auch auf die hierin ref erenzierten Rohdaten 36 
des Feldgerats 3 3 zuzugreifen. GemaS Figur 5 wird (werden) 
15 zu diesem Zweck mit Hilfe der Browser-Einrichtung 31 zunachst 
die HTML-Seite (n) 35 von dem Nutzer-Personalcomputer 30 ange- 
fordert. Nachdem der HTTP-Server 34 des Feldgerats 33 die 
HTML-Seite (n) 35, einschliefilich der hierin enthaltenen R'efe- 
renzen auf die Rohdaten 36, bereitgestellt hat, werden die 
20 HTML-Seite 35 und die Rohdaten 36 an den Nutzer-Personal- 
computer 30 ubertragen. Hierbei werden die HTML-Seite 35 und 
die Rohdaten 36 mitt els getrennter Protokolle zwischen dem 
Feldgerat 33 und dem Nutzer-Personalcomputer 30 tibertragen, 

i 

vorzugsweise HTTP-bzw. RPOProtokoll . In dem Nutzer- 
25 Personalcomputer 30 konnen die Rohdaten 36 dann mit geeigne- 
ten Programmen verarbeitet werden. Zum Ausfuhreii des RPC- 
Protokolls umfasst das Feldgerat 33 zusatzlich einen RPC- 
Server 34a. 

30 Beim Herunterladen der HTML-Seite 35 vom HTTP-Server 34 kon- 
nen die ref erenzierten Dateien der Rohdaten 3 6 automatisch 
mit geladen werden. Der Aufruf aus der HTML-Seite 35 kann 
wie folgt aussehen: < EMBED SRC^rawdata.ext 1 ^ . Mit dem Para- 
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meter „SRC U wird die Datei mit den Rohdaten 3 6 des Feldgerats 
33 ref erenziert . Aufierdem kann das He runt er laden der Rohda- 
ten 3 6 auch uber einen vom Benutzer zu aktivierenden Link auf 
der HTML-Seite 35 ausgelost werden. Fur diesen Fall konnte 
der Aufruf in der HTML-Seite 35 wie folgt aussehen: 
<a href= n rawdata.ext" type="mime type" >link</a> . 

Damit die Browser-Einrichtung 31 das richtige Programm zur 
Weiterverarbeitung der Rohdaten 3 6 starten kann, muss der 
Browser-Einrichtung 31 der Inhaltstyp der Rohdaten 3 6 mitge- 
teilt werden. Hierfur gibt es je nach verwendetem Betriebs- 
system des Nutzer-Personalcomputers 3 0 und genutzter Browser- 
Einrichtung 31 unterschiedliche Vorgehensweisen. Es kann so- 
wohl die Dateierweiterung (beispielsweise "*.ext n ) als auch 
der vom HTTP-Server 34 mitgelief erte MIME-Typ (MIME - Multi- 
purpose Internet Mail Extension") ausgewertet werden. Das 
von der Browser-Einrichtung 31 gestartete Programm zur Rohda- 
tenverarbeitung ubernimmt die Konvertierung der heruntergela- 
denen Rohdaten 36. Das Programm zur Rohdatenverarbeitung 
kann als Brows er-Plugln, als ActiveX-Komponente oder als ex- 
ternes Programm realisiert werden. 

Hierbei ist zwischen verschiedenen Typen von Rohdaten zu un- 
terscheiden. Die Verarbeitung von sporadisch entstehenden 
Rohdaten 36 wird vorzugsweise mit Hilfe.eines Browser- 
Plugln's oder einer Active X-Komponente vorgenommen. In die- 
sem Zusammenhang erfolgt der Zugriff auf die Daten mit Hilfe 
des TCP-Protokolls . : Sollen sich standig aktualisierende Roh- 
daten 3 6 in Form eines Endlos-Datenstroms verarbeitet werden, 
darm ist es sirinvoll, ein effektiveres Protokoll fur die U- 
bertragung an den Nutzer-Personalcomputer 30 (den Nutzerein- 
richtungen N1..NN) zu verwenden. Mit Hilfe des zusatzlichen 
RPC-Protokolls wird eine Auftrennung der in den Nutzerein- 
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richtungen Nl . . . NN (bzw. dem Nutzer-Personalcomputer 30) dar- 
zustellenden Informationen uber das (die) Feldgerat(e) 
FG1. . . FGN bzw. 33 in statische und dynamische Informationen 
ermoglicht. Die statischen Informationen werden mit dem 
5 HTTP-Standardprotokoll ubertragen, wahrend die dynamischen, 
also veranderlichen Daten uber das effektivere RPC-Protokoll 
ubertragen werden. Der Auf wand, der beim Senden der dynami - 
schen Daten mittels des HTTP-Protokolls durch Verbindungsauf - 
bau/-abbau und Verbindungsuberwachung entstehen wurde, wurde 
10 den des ereignisabhangigen, wiederholten Sendens der dynami - 
schen Daten mittels des RPC-Protokolls ubersteigen. Da in 
der Regel nur wenige Daten schnell ubermittelt werden soilen 
(Messwerte, Meldelisten, ...) 7 ist der Einsatz eines verbin- 
dungslosen Protokolls, insbesondere des RPC-Protokolls, fur 
15 die dynamischen Daten vorteilhaft. Bei einem Aufruf entfern- 
ter Prozeduren (RPC - /7 Remote Procedure Call") ruft ein loka- 
les Programm eine Prozedur auf einem entfernten System auf . 
Das Konzept des entfernten Prozedurauf ruf s sorgt dafiir, dass 
der gesamte Netzcode in der RPC-Schnittstelle und in den 
20 Metzroutinen verborgen bleibt. Damit wird vermieden, dass 
sich die Applikationsprogramme (Client und Server) urn De- 
tails, wie z.B. Konvertierung EBCDIC < > ASCII, Zahlenkon- 

vertierung, Socket, Session etc., kummern mussen. Ein Ziel 
von RPC ist die Vereinf achung der Implement ierung von ver- 
25 teilten Anwendungen. UDP (UDP - „User Defined Protocol'') wird 
von einigen Anwendungen, die nur kurze Nachrichten senden und 
diese wiederholen konnen, verwendet . UDP ist daher ein idea- 
les Protokoll zur Verteilung von Informationen, die sich 
standig andern, wie beispielsweise Borsenkurse. Statt die Da- 
3 0 ten in ein TCP- Urns chlag zu packen und dann in den IP- 

Umschlag, wandern sie jetzt in einen UDP-Umschlag, bevor sie 
in den IP-Umschlag kommen. Obwohl UDP in der gleichen Schicht 
wie das verbindungsorientierte TCP beheimatet ist, handelt es 
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sich um ein verbindungsloses Protokoll. Der Einsatz des UDP 
Protokolls erscheint immer dann sinnvoll, wenn nur wenige Da- 
ten schnell ubermittelt werden sollen. So gibt es in Anwen- 
dungsprogrammen zwischen Client und Server einen Austausch 
von kurzen Anfragen und Antworten. Hier wurde der Aufwand der 
durch Verbindungsaufbau/ -abbau und Verbindungsuberwachung 
entsteht, den des errieuten Sendens der Daten ubersteigen. Das 
getrennte Ubertragen von statischen und dynamischen Daten 
zwischen den Feldgeraten FG1...FGN im Geratenetzwerk und den 
Nutzereinrichtungen Nl . . . NN im Firmen- Intranet mit Hilfe un- 
terschiedlicher Protokolle wird durch d,as Vorsehen und die 
spezifische Ausbildung des spater im Detail beschriebenen 
Proxyservers 1 optimiert. 

Im folgenden wird die Nutzung des RPC-Protokolls zum Abrufen 
der. dynamischen Daten in einer Client/ Server- Anordnung (Nut- 
zereinrichtungen Nl . . .NN/Feldgerate FG1...FGN) anhand der 
schematischen Darstellung in Figur ,6 beschrieben. 

Ein RPC-Aufruf lauft beispielsweise wie folgt ab: 

(a) Ein innerhalb des Brwosers 31 (vgl . Figur 4) ablaufender 
Client-Prozess 100 ruft eine RPC-Schnittstelle 101 auf . 
Dieser Client-Prozess 100 kann z.B. ein in eine HTML- 
Seite eingebettetes Java-Applet sein. Die RPC- 
Schnittstelle 101 hat die Aufgabe, den Unterprogrammein- 
sprung zu spezif izieren. Die Spezif ikation enthalt den 
Namen der Funktion sowie Anzahl und Typen der Parameter. 
Hiermit wird ein logischer Einsprung def iniert . Die RPC- 
Schnittstelle 101 ermoglicht das Starten der entfernt 
liegenden Prozedur 102 . 

(b) Die Parameter des Client-Prozesses 100 werden von der 
RPC-Schnittstelle 101 gelesen. Der Zweck der RPC- 
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Schnittstelle 101 liegt in der Verpackung und Konvertie- 
rung der Parameter fur das Serverprogramm. 

(c) Die Netzroutinen versenden die Nachrichten an einen Ser- 
ver-Prozess 103, der im RPC-Server 34a ablauft. 

(d) Eine RPC-Schnittstelle 104 des Server-Prozess 103 baut 
die Parameter aus den Nachrichtenpaketen wieder auf . 

(e) Im nachsten Schritt wird das Serverprogramm aufgerufen. 
Dazu wird ein Serverstub definiert. Dieser Stub ist der 
eigentliche Einsprung in die auf dem Server-Prozess 103 
1 i egende Pr o z e dur . 

(f ) Nach Abarbeitung der Prozedur wird die Kontrolle wieder 
an die RPC-Schnittstelle 104 gegeben. 

(g) Die Schnittstelle 104 verpackt die Riickgabeparameter und 
transportiert die Daten anschlieSend zu den Netzroutinen. 

(h) Die Netzroutinen transportieren die Daten uber netzwerk- 
abhangige Aufmfe auf den Client-Prozess 100. 

(i) Die RPC-Schnittstelle 101 des Client-Prozesses 100 ent- 
packt die Parameter und versorgt die angegebenen Parame- 
ter mit den neuen Daten. 

(j) Die Kontrolle wird an den Client-Prozess 100 zuriickgege- 
ben, der die erhaltenen Daten weiterverarbeiten kann. 

Das Konzept des entfernten Prozedurauf ruf s sorgt dafur, dass 
der gesamte Netzcode in der RPC-Schnittstelle und in den 
Netzroutinen verborgen bleibt . Damit wird vermieden, dass 
sich die Applikationsprogramme (Client und Server) urn De- 
tails, wie z.B. Konvertierung EBCDIC < > ASCII, Zahlenkon- 

vertierung, Socket, Session etc., kummern muss en . Ein Vor- 
teil der Nutzung des RPC-Protokolls fur die dynamischen Daten 
ist die Vereinf achung der Implementierung von verteilten An- 
wendungen . 
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Bedienen der Feldgerate 

Der in Verbindung mit Figur 4 beschriebene Abruf von Informa- 
tion von dem Feldgerat 33, welches den HTTP-Server 34 um- 
5 fasst, kann auch in Verbindung mit Handlungen im Rahmen des 
Beobachtungs- und Bediensystem genutzt werden, die zum Zweck 

des Bedienens des Feldgerats 33 ausgefiihrt werden. Hierdurch 

» 

ist es ermoglicht, das Feldgerat 33 mit Hilfe der Browser- 
Einrichtung 31 zu bedienen. Dieses wird im folgenden naher 
10 beschrieben . 

Das Feldgerat 33 enthalt eine Speichereinrichtung 35a, in 
welcher Bediensof tware in Form von HTML-Seiten 35 gespeichert 
ist, und ein Java-Archiv oder Daten, aus denen HTML-Seiten 

15 erzeugbar sind. Die Bediensof tware ist speziell auf das 
Feldgerat 33 zugeschnitten. Mittels der Eingabe der URL- 
Adresse des Feldgerats 3 3 durch den Nutzer startet ein HTTP- 
Herunter laden, was zum Herunter laden der Bediensof tware vom 
HTTP-Server 34 des Feldgerats 33 in den Nutzer-Personal- 

20 computer 30 fuhrt. Nach dem Herunterladen der Bediensof tware 
von dem Feldgerat 3 3 auf den Benutzer-Personalcomputer 30 in 
Form der HTML-Seite (n) 35 wird die Vorderansicht des Feldge- 
rats 33 mit alien Bedien- und Anzeige-Elementen innerhalb der 
Browser-Einrichtung dargestellt (vgl . Figur 3). Der Benutzer 

25 kann dann bestimmte Bedienf unktionen des Feldgerats 33 mit 
Hilfe eines Mausklicks auf dem Bildschirm des Benutzer- 
Personalcomputers 3 0 auslosen. Die Ubermittlung der Benut- 
zerhandlung zum Feldgerat 33 erfolgt mittels eines schnellen 
und effektiven Protokolls, das einerseits die genannten Be- 

30 dienanf orderungen vom Benutzer-Personalcomputer 3 0 zum Feld- 
gerat 33 ubertragt und andererseits Reaktionen des Feldgerats 
33 zuruckliest. Zu diesem Zweck werden die internen Bedien- 
und Anzeigef unktionen. des Feldgerats 33 zur Schnittstelle der 
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Browser-Einrichtung 31 hin verof f entlicht , z.B. Tastaturpuf - 
fer, Displaypuf f er, LED-Status. 

Im Rahmen der Bedienung durch den Benutzer gibt es zwischen 
5 Benutzer— Per sonalcomputer 30 und dem Feldgerat 3 3 einen Aus- 
tausch von kurzen Anfragen und Antworten im Rahmen einer 
Client -Server-Verhaltnisses . Hierbei wtirde der Aufwand, der 
im Zus ammenhang mit dem Aufbau/Abbau und der Uberwachung der 
HTTP-Verbindung zwischen dem Benut z er- Per sonalcomput er 3 0 und 

10 dem Feldgerat 33 entsteht, den Aufwand tibersteigen, der beim 
erneuten Senden und Empfangen der Daten gemafi eines verbin- 
dungslosen Protokolls entsteht. Da in der Regel riur wenige 
Daten schnell ubermittelt werden sollen (z.B. Tastendruck, 
Displayinhalt , LED-Status), ist der Einsatz eines schnellen, 

15 effektiven, verbindungslosen Protokolls sinnvoll, beispiels- 
weise des oben beschriebenen RPC- Protokolls . Zur Reduktion 
der ausgetauschten Datenmenge (z.B. Displayinhalt) zwischen . 
dem Benutzer— Personalcomputer 3 0 und dem Feldgerat 33 werden 
Verfahren zur Komprimierung von Daten eingesetzt. 

20 

Internet-Protokolle, wie TCP/IP und HTTP, bieten keinerlei 
Sicherheitsmechanismen. Es sind zusatzliche Protokolle not- 
wendig, urn eine sichere Kommunikation zu ermoglichen. Die Me- 
chanisraen zum Schutz sicherheitsrelevanter Aktionen am Feld- 

2 5 gerat 3 3 uber TCP/IP- Kommunikation sind von besonderer Bedeu- 

tung. Hinsichtlich des Schutzes gegen unbefugte Zugriffe 
lassen sich die Bedienhandlungen am Feldgerat 33 klassifizie- 
ren (vgl . Tabelle 1) . 

3 0 Tabelle 1 



Aktion 


Sicherheits-Risiko 


MaSnahmen 


Messwerte le- • 
sen; 


Gering - beim Mitlesen des 
RPC - Da t enve r kehr s konnen 


Es wird ein internes 
UDP-Protokoll (UDP - 



WO 03/036400 



PCT/DE02/03849 



19 



Aktion 


Sicherheits-Risiko 


Mafinahmen 


Meldungs listen 
lesen 


Inf ormationen zur Be- 
triebsfuhrung (Betriebs- 
inessweruc, i*ieJ-aung en, 
Storfaile) itn Umfang der 
auf den HTML-Seiten ange- 
zeigten Daten eingesehen 

W J. UC11 


„User Defined Proto- 
col w ) verwendet . Da 

UlCbcb JrXU LUJV.UJ.X J.AU.JL 

dem Hersteller be- 
kannt ist, ist fur 
das Entschlusseln 
der Inhalte ein Re- 
Engineering notwen- 
dig 


Gerat umpara- 
metrieren 


Hoch - diese Aktionen sind 
am Gerat pas swortgesi chert 


Optionale Verschlus- 
selurig der sehr kur- 
zen Protokolle (auf- 
wandig) 


Schalten, Steu- 
ern, Puffer 16- 
schen 


Sehr hoch - die Protokolle 
konnen auf gezeichnet und 
spater wiederholt werden 


12 8-Bit-Verschlus- 
selung pas swortgesi - 
cherter Aktionen 



Missbrauchliche Handlungen beim Bedienen des Feldgerats 33 
konnen mittels der folgenden MaSnahmen im wesentlichen ausge- 
5 schlossen werden: 

Mit Hilfe einer Firewall (z.B. Proxyserver) kann das interne 
Netz (Firmen- Intranet /LAN) eine geschutzte Verbindung mit ei- 
nem anderen Netz (z.B. Internet) aufnehmen. 

10 

Das Feldgerat 33 ist im Lief erzustand so eingestellt, dass 
Tasten, die die vollstandige Eingabe von Kundenpasswdrtern er- 
moglichen, gesperri sind. Diese Sperre muss vom Kunden am 
Feldgerat 33 selbst bzw. mit dem Bedienprogramm in der Brow- 
15 ser-Einrichtung 31 auf dem Nut zer- Personal computer 3 0 aufgeho- 

ben werden {Passworteingabe erf orderlich) . Im Lief erzustand 
sind damit nur einfache Bedienhandlungen iiber die Browser- 
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Einrichtung 31 moglich: Navigation ,im Bedienmenu, Anzeige von 
Messwerten, Parametern und Meldungslisten. 

Die Parametrierung des Feldgerat s 33 in der Front ansicht- 
Emulation ist mit Kenntnis der Passworter wie am Feldge- 
rat 33 moglich, wenn die Sperrung der dazu benotigten 
Tasten gelost ist. 

Sicherheitsrelevante Aktionen am Feldgerat 33 (Schalten, 
Steuern, Loschen von Puffem, . . . ) werden durch Authenti- 
f ikationsprotokolle geschiitzt, z.B. mittels Hash -Funkt ion 
und eines vom Feldgerat 33 generierten Schlussels. Damit 
konnen aus dem Verbindungsprotokoll keine Ruckschlusse 
auf eingegebene Passworter erfolgen. Mit diesem Verfah- 
ren wird aus einer beliebig langen Nachricht eine 128 Bit 
lange Information, der sogenannte „Message Digest u , ge- 
bildet, der an die originare Nachricht angehangen wird. 
Der Empf anger (Feldgerat 33) vergleicht den ^Message Di- 
gest u mit dem vom Feldgerat 33 aus der Information ermit- 
telten. Dadurch werden Feldgeratepassworter nicht uber 
die Kommunikationsverbindxing ubertragen . 

Die itn Feldgerat 33 generierten Schlussel verfallen nach 
kurzer Zeit und konnen nur einmal fur eine Ubertragung 
verwendet werden. Damit ist die Aufzeichnung von sicher- 
heitsrelevanten Protokollen und eine spatere Wiederholung 
dieser auf gezeichneten Protokolle wirkungslos. 

Proxy server 

Ein Element zur optimierten Umsetzung des beschriebenen funk- 
tionellen Zusammenwirkens der Elemente des Beobachtungs- und 
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Bediensys terns, beispielsweise der Nutzung des RPC-Protokolls , 
des Abrufs der Rohdaten aus den Feldgeraten FG1 . . . FGN und der 
Bedienung der Feldgerate mittels Browser auf den Nutzerein- 
richtungen N1...NN, ist der Proxyserver 1. Bekannte Stan- 
5 dard-HTTP- Proxyserver unterstiitzen ausschlieSlich das HTTP- 
Protokoll und sind somit nicht in der Lage, als Gateway zwi- 
schen dem Geratenetzwerk und dem Firmen- Intranet zu dienen. 
Aus diesem Grund wurde ein spezif ischer , fur das BuB-System 
*• konzipierter Proxyserver 1 geschaffen, der beide von den 
10 Feldgeraten FG1 . . . FGN verwendeten Protokolle (HTTP, RPC) un- 
* terstutzt. 

Ein wesentlicher Vorteil, der bei der Nutzung des Proxyser- 
vers 1 gegenuber der Ankopplung des Geratenetzwerks an das 
15 Firmen- Intranet mittels Routers oder, wenn keine WAN- 

Verbindung (WAN - „Wide Area Network") zwischen dem Gerate- 
netzwerk und dem Intranet besteht, einer direkten Ankopplung 
des Gerate-Netzsegments uber einen Hub oder einen Switch be- 
steht in der Nutzung des sogenannten „Cachings w . 

20 

Das diesem Verfahren („Caching u ) zugrunde liegende Prinzip 
wird im folgenden allgemein, ohne Bezugnahme auf die oben ge- 
nannten Figuren, kurz beschrieben. 

25 Stellt ein Client eine Anfrage nach einem Objekt an eine Ser- 
vereinrichtung, so lauft diese Anfrage zunachst uber eine so- 
genannte Proxy-Einrichtung . Die Proxy-Einrichtung schaut 
nach, ob sich das betreffende Objekt bereits in einem lokalen 
Speicher (Cache) der Proxy-Einrichtung befindet, welcher in 

3 0 der Regel auf einer Festplatte ausgebildet ist. Wird hierbei 
f estgestellt , dass das Objekt nicht lokal im Speicher vor- 
liegt, reicht die Proxy-Einrichtung die Anfrage weiter zu ei- 
ner eigentlichen Zielserver-Einrichtung . Von dort erhalt die 
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Proxy -Einrichtung das Objekt und speichert eine Kopie des Ob- 
jekts fur weitere Anfragen nach diesera Objekt in dem lokalen 
Speicher, bevor die Proxy-Einrichtung das Objekt an den an- 
fragenden Client weitergibt. Wird das Objekt jedoch im loka- 
5 len Speicher der Proxy-Einrichtung gefunden, so wird die An- 
frage des Clients nicht an die Zielserver-Einrichtung durch- 
gestellt, sondern der Client bekommt das gewiinschte Objekt 
direkt von der Proxy-Einrichtung ubermittelt . Voraussetzung 
fur optimales Ausfuhren des beschriebenen Verfahrens ist.ein. 

10 gemigend groSer Speicher-Bereich in iier Proxy-Einrichtung, 

d.h. in der GroBenordnung von mehreren Hundert MB bis mehre- 
ren GByte. Ansonsten lauft der lokale Speicher in der Proxy- 
Einrichtung liber und es muss ein „Garbage Collector" (ein so- 
genannter Auf raumdienst ) gestartet werden, der veraltete Ob- 

15 jekte aus dem Speicher heraus filtert, urn dort Platz fur neue 
Objekte zu s chaff en. 

Vorteile des beschriebenen Verfahrens („ Caching") sind: eine 
Verbesserung der Leistungsf ahigkeit (schnellerer Datentrans- 
20 port als extern); eine Einsparung von ex t erne r Bandbreite 

(mehr Platz fur andere Dienste bleibt frei) ; eine Verminde- 
rung der Antwortzeiten 

Entlastung der Zielserver-Einrichtung; beim Transport des Ob- 
jekts von der Proxy-Einrichtung zum Cli'ent entstehen keine 
25 bzw. geringere Ubertragungskosten; und die Tref f erquoten im 

lokalen Speicher der Proxy-Einrichtung konnen je nach Nutzung 
sehr hoch sein. ; 

Der zum Verbinden des Geratenetzwerks und des Firmen- 
30 Intranets (vgl. Figur 1) genutzte Proxyserver 1 basiert auf 
dem beschriebenen Grundprinzip und hat aufgrund der spezifi- 
schen Ausbildung # welche im Detail spater beschrieben wird, 
daruber hinaus die im folgenden genarinten Vorteile. 
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Durch den Einsatz des Proxyservers 1 (vgl . Figur 1) ergeben 
sich deutliche Geschwindigkeitsvorteile beim Zugriff auf das 
Geratenetzwerk. Der Proxyserver 1 umfasst einen fur die An- 
5 wendung im BuB-System optimierten Dateispeicher bzw. Dateica- 
che, der alle aus den Feldgeraten FG1...FGN abgerufenen Da- 
teien mit statischen Daten im Proxyserver 1 puffert. Wird 
. auf eine solche Datei das erste Mai zugegriffen, dann muss 
>- diese Datei direkt aus einem der Feldgerate FG1...FGN geholt 
10 - werden. Bei einem wiederholten Zugriff auf diese Datei kann 
• diese dann jedoch direkt aus dem Dateicache des Proxyservers 
1 geliefert werden. Da das lokale Firmen- Intranet im allge- 
meinen viel schneller als eine Modemverbindung zu den Feldge- 
raten FG1...FGN ist, ergeben sich hier signifikante Geschwin- 
15 digkeitsvorteile beim Zugriff auf das Geratenetzwerk, da im 
laufenden Betrieb nur noch die gegenuber den HTML-Seiten und 
den Java-Archiven deutlich kleineren dynamischen Daten uber 
die langsame Modemverbindung ubertragen werden. 

2 0 Der Proxyserver 1 erhoht daruber hinaus die Sicherheit im 

Netzwerk. Der Proxyserver 1 schottet die beiden Netzwerke, 
Geratenetzwerk und Firmen- Intranet , gegeneinander ab und u- 
bertragt nur die im Proxyserver 1 verarbeiteten Protokolle. 
Dies bedeutet, dass aus dem Firmen- Intranet nur die von einem 
25 Browser auf den Nutzereinrichtungen N1...NN an die Feldgerate 
FG1...FGN generierten Anf orderungen ubertragen werden. In 
die Gegenrichtung werden nur die von den Feldgeraten 
FG1...FGN generierten Antworten ubertragen. Damit werden al- 
le anderen im Firmen- Intranet kursierenden Datenpakete vom 

3 0 Geratenetzwerk ferngehalten und beeinflussen somit nicht den 

Durchsatz im Geratenetzwerk. Des weiteren kann ein im Gera- 
tenetzwerk auf tretendes, hohes Datenauf kommen aufgrund von 



WO 03/036400 



PCT/DE02/03849 



24 

Querkommunikatiori zwischen den Feldgeraten FG1...FGN die 
Netzlast itn Firmen- Intranet nicht erhohen. 

Die Nutzung des RPC-Protokolls mittels des Proxyservers 1 
5 hat den Vorteil, dass sichergestellt ist, dass die Zugriffs- 
moglichkeit auf die Feldgerate FG1....FGN auf das an den Pro - 
xyserver 1 angeschlossene Firmen- Intranet beschrankt bleibt. 
Ein Firmen- Intranet ist heute liblicherweise uber ein HTTP- 
Gateway mit dem Internet verbunden. Dieses Gateway ubernimmt 

10 hier eine Firewall-Funktion (vgl . Figur 7), indem es die U- 

bertragung des RPC-Protokolls blockiert. Hierdurch kann au- 
fierhalb des Firmen- Intranets nicht mehr auf die Daten der 
Feldgerate FG1...FGN zugegriffen werden, da alle dynamischen 
Daten der Feldgerate FG1 . . . FGN uber das RPC-Protokoll uber- 

15 tragen werden. 

Der Proxyserver 1 ermoglicht vielfaltige Funktionen, die bei 
dem bisher ublichen, direkten Zugang zu den Feldgeraten 
FG1...FGN nicht zur Verfugung stehen. Die folgende Zusammen- 

2 0 stellung listet weitere wesentliche Funktionen auf, die sich 

in Verbindung mit der nachf olgenden, detaillierten Beschrei- 
bung des Proxyservers 1 ergeben: 

Es wird eine eigene Homepage zur Verfugung gestellt, uber 
die alle angeschlossenen Feldgerate FG1...FGN erreichbar 
25 sind. 

- Die angeschlossenen Feldgerate FG1...FGN werden automa- 
tisch adressiert und erkannt; Darstellung dieser Feldgera- 
te FG1...FGN in der Homepage als Startseite auf den Nut- 
zereinrichtungen N1...NN fur einen direkten Geratezugrif f . 

3 0 Es wird der Zugriff uber Geratenamen der Feldgerate 

FG1...FGN ermoglicht, dies ist gegenuber dem Zugriff uber 
die IP-Adresse nutzerf reundlicher . 
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Der Proxyserver 1 kann mittels Browser auf den Nutzerein- 
richtungen N1...NN konfiguriert werden ( e-mail -Adressen, 
Telef on-Nummem, Geratenamen, . . . ) 

Der Proxyserver 1 definiert die moglichen Zugriffswege 
5 („ Firewall -Funktion") . 

Der Proxyserver 1 kann Daten aus den Feldgerate FG1 . . .FGN 
zwischenspeichern . Diese Funktion eignet sich z. B. fur 
. die Protokollierung der Storf allinf ormationen oder der Be- 
triebsmesswerte . Diese Daten werden intern in einer XML- 

10 Datenbank (XML - ^Extended Markup Language") abgelegt. 

Der Proxyserver kann die aus den Feldgeraten FG1 . . . FGN li- 
ber das RPC-Protokoll ubertragenen Daten im XML-Format zur 
Verfiigung stellen. Hierdurch konnen beispielsweise nut- 
zerspezif ische Erweiterungen der im Proxyserver 1 verfug- 

15 baren Darstellungen vorgenommen werden. Hierzu steht ein 

im Proxyserver 1 integrierter XSL- Parser (XSL - „ Extended 
Stylesheet Language w ) zur Verfugung. 
- Durch die mit Hilfe des XSL-Parsers realisierbaren Filter 
auf die XML-Datenbank kann der Proxyserver 1 ebenfalls als 

2 0 Client fur weitere Applikationen genutzt werden. 

Signalisierung von Ereignissen im LAN (LAN - „ Local Area 
Network") via e-mail ist moglich. Der Proxyserver 1 stellt 
eigene e-mail-Postf acher zu Verfugung, die mittels eines 
POP3-Clients (P0P3 - „Post Office Protocol Stepping 3"), 
25 wie z.B. Outlook, abgerufen werden konnen. Weiterhin ist 

eine Weiterleitung von e-mails an ein anderes Postfach 
mittels eines im Proxyserver 1 integrierten SMTP-Servers 
(STMP - „Simple Message Transfer Protocol") moglich. 

3 0 Im folgenden wird die Ausbildung des Proxyservers 1 naher be- 

schreiben. 
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Figur 7 zeigt eine Anordnung mit dem. Geratenetzwerk und dem 
Firmen- Intranet gemafi Figur 1, wobel Elemente des Proxyser- 
vers 1 schematisch gezeigt sind. Figur 8 zeigt Funktionsblo- 
cke des Proxyservers 1 in einem Blockschaltbild . 

5 

GemaS Figur 7 weist jedes der Feldgerate FG1 . . . FGN einen je- 
weiligen HTTP-Server HS1...HSN auf, die dem jeweiligen HTTP- 
Server 34 (vgl. Figur 4) entsprechen 1 und mit einem Sternkopp- 
ler 3 9 verbunden sind. Der Proxyserver 1 verfugt ebenfalls 
10 uber einen HTTP-Server 40. Im folgenden wird die Arbeitswei- 
se des Proxyservers 1 unter Bezugnahme auf Figur 8 beschrie- 
ben. 

Der Zugriff auf den Proxyserver 1 geschieht immer aus dem lo- 
15 kalen Netz des Firmen- Intranets heraus, in dem sich die Nut- 
zereinrichtungen Nl . . .NN mit der jeweiligen Modemverbindung 
in das die Feldgerate umfassende Geratenetzwerk befinden, das 
ein Umspannwerk oder mehreren Unterwerken umfassen kann. Wird 
eine der Nutzereinrichtungen N1...NN uber die zugehorige lo- 

2 0 kale IP-Adresse als Server angesprochen, wird dieser Zugriff 

uber einen TCP/IP-Stack 41 (TCP - ^Transfer Control Proto- 
col w ) an den HTTP- Server 40 weitergeleitet . 

Der HTTP- Server 4 0 liefert die angef orderten Dateien in das 
25 Firmen- Intranet . Zu diesem Zweck wendet sich der HTTP-Server 
40 uber einen Dateifilter 42 an eine Cacheverwaltung 43. Der 
Dateifilter 42 leitet die Anforderung normalerweise an die 
Cacheverwaltung 43 weiter. Nur bestimmte Anf orderungen wer- 
den anhand des angef orderten Dateityps erkannt und einem an- 

3 0 deren Verarbeitungsweg zugef uhrt . Diese Ausnahmen werden 

spater beschrieben. Die Cacheverwaltiing 43 versucht als ers- 
tes, die angef orderte Datei in den lokalen Dateien 44 oder in 
einem Dateicache 45 zu finden. 1st die angef orderte Datei 
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weder eine lokale Datei des Proxyservers 1 noch im Dateicache 

45 vorhanden, wird die Dateianf orderung an einen HTTP-Client 

46 weitergeleitet . Dieser baut uber einen weiteren TCP/ IP- 
Stack 47 eine Verbindung zum HTTP-Server HS1, . . . bzw. HSN 

5 des angesprochenen Feldgerats FG1, . .. bzw. FGN im Gerate- 

netzwerk auf , urn die angeforderte Datei von dort zu beziehen. 

Als Verbindung zum Geratenetzwerk wird vorzugsweise eine Mo- 
demverbindung mit dem PPP-Protokoll genutzt (vgl . Figur 1) . 

10 Da der Proxyserver 1 uber diese Modemverbindung jedoch 

gleichzeitig mehrere Verbindungen zu verschiedenen Feldgera- 
ten FG1 . . . FGN halten kann, ist eine Arbitierung dieter Modem- 
verbindung erforderlich, da das PPP-Protokoll nur eine Punkt- 
zu Punkt -Verbindung verwalten kann. Hierzu dient ein Block 

15 Slot-Protokoll 48. Dieses Protokoll teilt den einzelnen PPP- 
Verbindungen Zeitscheiben auf der Modem- Kommunikationsstrecke 
zu und verhindert so Kollisionen zwischen den einzelnen Ver- 
bindungen. Der Block Slot-Protokoll 48 ist weiterhin dafiir 
zustandig, alle im Geratenetzwerk aktiven Feldgerate 

20 FG1...FGN zu erkennen. Dazu wird das Geratenetzwerk zyklisch 
nach aktiven Feldgeraten abgesucht. Die erkannten aktiven 
Feldgerate werden von einer Gerateverwaltung 4 9 in eine XML- 
Datenbank 50 des Proxyservers 1 eingetragen. 

25 Bei der XML-Datenbank 50 handelt es sich um einen nach dem 
standardisierten „Document Object Model w abgelegten Daten- 
baum. Enthalt nun eine uber den HTTP- Server 4 0 in den Brow- 
ser einer mit dem Proxyserver 1 verbunden Nutzungseinrichtung 
Nl, ... bzw. NN geladene HTML-Seite Java-Code, der eine pa- 

30 rallele UDP -Verbindung (UDP - ff User Defined Protocol 1 ') fur 
das RPC-Protokoll auf baut, dann wird uber diesen Weg ein 
RPC- Server 51 aus dem Firmen- Intranet heraus angesprochen. 
Da das RPC-Protokoll aus Leistungsgrunden auf das standard!- 
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sierte UDP/IP-Protokoll aufsetzt, muss hier im Proxyserver 1 
eine Verbindungsverwaltung 52 enthalten sein, da das UDP- 
Protokoll . nicht verbindungsorientiert arbeitet. Die Verbin- 
dungsverwaltung 52 stellt sicher, dass fur jede Nutzungsein- 
richtung N1...NN aus dem Firmen- Intranet ein eigener Kommuni- 
kationsport fur einen RPC-Client 53 des Proxyservers 1 in das 
Geratenetzwerk reserviert wird. Die RPC-Anf orderungen aus 
dem Firmen- Intranet werden dann liber den RPC-Client 53 des 
Proxyservers 1 direkt in das Geratenetzwerk weitergeleitet. 

Die Antworten der Feldgerate FG1 . . FGN auf RPC-Anf orderungen 
werden an den RPC-Server 51 weitergeleitet. Dieser gibt die 
Antwort des jeweiligen Feldgerats FG1 , ... bzw. FGN an die 
Nutzereinrichtungen liber das Firmen- Intranet weiter. Paral- 
lel hierzu werden die aktuell im RPC^Protokoll ubertragenen 
dynamischen Daten aus dem jeweiligen Feldgerat FG1 # . . . bzw. 
FGN in der XML-Datenbank 50 im Proxyserver 1 abgelegt . 

Die in der XML-Datenbank 50 gespeicherten Daten konnen mit 
Hilfe eines im Proxyserver 1 integrierten XSL-Parsers 54 in 
beliebige andere Datenformate konvertiert werden. Die dazu 
notwendigen Transf ormationsanweisungen mussen als XSL- 
Scriptdatei lokal im Proxyserver 1 abgelegt werden. Urn einen 
solchen Transf ormatdonsprozess auszulosen, muss am HTTP- 
Server 4 0 eine *.XML-Datei angefordert werden. Eine solche 
Anforderung wird von dem am HTTP-Server 4 0 angeschlossenen 
Dateifilter 42 aus dem normalen Zugriffsweg auf die Cachever- 
waltung 43 herausgef iltert und an den XSL-Parser 54 weiterge- 
leitet. Dieser liest aus den im Proxyserver 1 lokal abgeleg- 
ten Dateien neben der angef orderten XML-Datei eine gleichna- 
mige XSL-Datei und startet den Transf ormationsprozess . Das 
Ergebnis dieser Transformation wird yom HTTP-Server 40 an den 
anfordernden Nutzer gesendet. Auf diese Weise konnen z. B. 
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HTML-Dateien dynamisch aus einer XSL-Vorlage mit den aktuel- 
len Daten der Feldgerate FG1...FGN aus der XML-Datenbank 50 
erzeugt oder einfach ein Teilbaum der Datenbank als XML-Datei 
ubertragen werden. 

Der Dateifilter 42, die Cache -Verwaltung 43, die lokalen Da- 
teien 44, der Dateicache 45, der XSL-Parser 54 sowie die XML- 
Datenbank 50 bilden ein Dateisystem des Proxyservers 1. 

Im folgenden werden einzelne Funktionsblocke des Proxyservers 
1 naher beschrieben. 

HTTP - Server 

Zunachst wird die grundsatzliche Arbeitsweise des im Proxy- 
server 1 ausgebildeten HTTP-Servers 40 (vgl . Figur 8) erlau- 
tert, wobei zum besseren Verstandnis einige wesentliche 
Grundlagen des HTTP*s beschrieben werden. 

Wie bei anderen Applikationsprotokollen im Internet handelt 
es sich bei HTTP (HTTP - „Hypertext Transfer Protocol ») urn 
ein ASCII -Protokoll, das fur den Datenaustausch eine abgesi- 
cherte TCP-Verbindung zwischen einem Client (Computer des In- 
ternetnutzers) und einem Server (Servereinrichtung, auf wel- 
cher abrufbare Internet inhalte - Daten - zur Verfugung ste- 
hen) benotigt. Als Ahkmipf ungspunkt ist dabei der Port 80 
definiert, d. h. , ein. HTTP- Server lauscht an diesem Port auf 
neue Client -Verbindungen . Alternativ kann die uberwiegende 
Anzahl von HTTP- Server;- Software uber einen entsprechenden 
Konf igurationsdialog auch angewiesen werden, einen anderen 
Port fur die Kontaktauf nahme heranzuziehen. 
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Anders als bei anderen Protokollen, z. B, FTP (FTP - „File 
Transfer Protocol u ) und POP3, ist eine Verbindung zwischen 
einem HTTP-Client und einem HTTP-Server sehr kurzlebig. Der 
HTTP-Client baut eine TCP-Verbindung zum gewunschten HTTP- 
5 • Server uber den Port 80 auf und setzt eine Anfrage nach einem 
gewunschten Dokument an den HTTP-Server ab. Der HTTP-Server 
erhalt die Anfrage, wertet sie aus und sendet - im Erfolgs- 
fall - das gewunschte Dokument an den HTTP-Client zuriick. 
Der HTTP-Server schlieSt die TCP-Verbindung automatisch, 
10 nachdem er dem HTTP-Client das geforderte Dokument oder eine 
Fehlermeldung als Antwort auf dessen Anfrage zugesandt hat . 

Eine wichtige Funktionalitat von HTTP ist es, dass der HTTP- 
Client dem HTTP-Server mitteilen kann, welche Art von Daten 
dieser verstehen kann. Es muss also bei jeder Anfrage eine 
Kommunikation zwischen dem HTTP-Client und dem HTTP-Server 
dariiber stattfinden, wie die Daten ubertragen werden sollen, 
Diese Kommunikation erzeugt einen sogenannten Uberschuss bzw. 
Uberhang („overhead w ) ; HTTP wird deshalb auch als statusloses 
Protokoll („ stateless protocol u ) bezeichnet, weil die Verbin- 
d-ung nicht mehrere Phasen durchlauft, vom Einloggen, liber den 
Datenaustausch bis hin zum Ausloggen durch den HTTP-Client. 
Dieses erleichtert einerseits die Entwicklung von HTTP- 
Client- /HTTP-Server-Software, ist aber im Hinblick auf die 
Nutzung der zur Verfugung stehenden Bandbreite nicht sehr ef- 
fizient. 

Das HTTP-Protokoll wird verwendet, urn Zugriff auf Quellen im 
URL- Format (URL - ^Uniform Resource Locator u ) zu erlangen. 
30 Der HTTP-Client, meistens ein Web-Browser auf dem Computer 

des Internet-Benutzers. Er verlangt eine HTML-Seite und gene- 
riert danach eine Sequenz von Anfragen bezuglich der Datei- 
verweise in dieser HTML-Seite. Danach wird der Benutzter 
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wahrscheinlich einen Link in der angefragten HTML-Seite an- 
klicken, und der HTTP-Client schickt eine Anfrage, bezuglich 
der mit diesem Link verkmipften HTML -Sei ten, an den gleichen 
oder einen weiteren HTTP-Server. Diese weiteren Kommunikati- 
5 onsverbindungen haben keine Inf ormationen mehr uber eine vor- 
hergegangene Verbindung. Dieses funktioniert bei einfachen 
Client/Server-Umgebungen. Bei umf angreicheren Kommunikatio- 
nen kann diese Arbeitsweise allerdings zum Problem werden, 
denn fur jede noch so kleine Datenmenge, die libertragen wer- 
10 den soil, fallt dieser Uberschuss („Overhead u ) an, was die 
Effizienz mindert. 

Figur 9 zeigt eine schematische Darstellung der Syntax einer 
Anfrage in Verbindung mit einer HTTP-Client/Server- 
15 Interaktion. 

Die HTTP-Client/Server- Interaktion besteht aus einer einzigen 
Anf rage/Antwort-Kommunikation. Sie umfasst eine „ request li- 
ne u , ein oder mehrere optionale „ request header fields w und 

20 einen optionalen „ entity body u . Von der HTTP-Client-Seite 
60, also in der Regel vom Internet -Browser aus, wird eine 
TCP-Verbindung zum HTTP-Server 61 geoffnet 62. Anschliefiend 
sendet der HTTP-Client 60 einen Kommandostring an den HTTP- 
Server 61. Der HTTP-Server 61 antwortet uber die vom HTTP- 

25 Client 60 geoffnete TCP-Verbindung mit einem Kopf, der neben 
der vom HTTP-Server 61 unterstutzten HTTP-Version auch den 
MIME-Type und die Kodierung der angef orderten Datei enthalt. 
An diesen Kopf im ASCII -Format wird vom HTTP-Server 61 der 
Inhalt der angef orderten Datei angef ugt . Nachdem der HTTP- 

30 Server 61 die komplette Datei gesendet hat, schlieSt dieser 
die vom HTTP-Client 60 geoffnete TCP-Verbindung wieder 63. 
Dieser Vorgang kann sich beliebig oft wiederholen. 
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Die folgende Zusammenstellung zeigt den Ablauf eines typi- 
schen HTTP-Zugrif f s : 

1. „ connection" (Verbindungsaufbau) 

• WWW-Client baut eine TCP/IP-Verbindung zum WWW- Server 
auf 

2. „request" (Anf orderung) 

• Angabe einer Zugrif f smethbde (GET, HEADER, POST...} 

• Spezif ikation des gewunschten Dokumentes mittels URL 

• Zusatzinf ormationen in Form von MIME-Header 

• Daten (bei POST) 

3. ^response" (Antwort) 

• Header mit Statuscode 

• Zusatzinf ormationen in Form von MIME-Header 

• Dokument in HTML- Format 

• Daten in sonstigen Formaten (Bilder, Sound...) 

4. „close w (Verbindungsabbau) 

• Im Normalfall vom HTTP-Server aus, nach Datenubertra- 
gung 

• Im Spezialfall vom HTTP-Client aus (Ubertragungszeit , 
Speicherplatz) 

5 Hierbei besteht die „ request . line w aus drei Textfeldern, wel- 
che durch Leerzeichen getrennt sind. Das erste Feld spezif i- 
ziert die Methode (oder das Kommando) . Das zweite Feld spe- 
zif izieirt den Namen der Quelle (ist die URL ohne die Angabe 
des Protokolls und des Hosts) . Das letzte Feld spezif iziert 
10 die verwendete Protokollversion des HTTP-Clients 60, bei- 
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spielsweise HTTP/1.0. Die ^request header fields* libergeben 
zusatzliche Inf ormationen liber die Anfrage und den HTTP- 
Client 60. Die Felder werden als eine Art RPC- Parameter be- 
nutzt. Jedes Feld besteht aus einem Namen, gefolgt von eine 
5 Doppelpunkt und dem Feldwert . Die Reihenfolge der „header 
fields w ist hierbei nicht wichtig. Der „ entity body" wird 
'manchmal von HTTP-Clients 60 verwendet, utn groSere Informati- 
onspakete an den HTTP -Server 61 zu senden. 

10 . Dateicache 

Um eine moglichst effiziente Arbeit der Cacheverwaltung 43 zu 
ermoglichen, arbeitet der Dateicache 45 nicht wie ublich mit 
der URL, dem Datum und der Lebensdauer der zu verwaltenden 

15 Dateien, sondern nutzt weitere Kriterie'n zur Identif izierung 
einer Datei. Wurden nur die drei genarmten Kriterien fur den 
Entscheid verwendet werden, ob eine lokal im Dateicache vor- 
handene Datei mit der im Feldgerat verfugbaren Datei iden- 
tisch ist, dann ware fur die Durchfuhrung dieses Tests ein 

2 0 Vergleich der genarmten Dateimerkmale erf orderlich. Dazu 

musste fur jede Datei der Kopf aus dem Feldgerat angefordert 
werden. Da das Dateisystem der Feldgerat e FG1...FGN jedoch 
nur als Einheit in Form eines KON-Dateien (konvertierte Da- 
teien - Format der in die Nutzereinrichtungen N1...NN ladba- 

25 ren Dateien) geladen werden kann, ist ein solcher Vergleich 

nicht fur jede Datei erf orderlich. Eine Ausnahme bilden hier 
die dynamisch in den Feldgeraten FG1...FGN erzeugten Dateien, 
beispielsweise die Datei MLFB.TXT (MLFB - Maschinenlesbare 
Fabrikantenbezeichnung) , die nicht aus dem Dateisystem der 

30 Feldgerate FG1 . . . FGN ausgelesen, sondern aus der im jeweili- 
gen Feldgerat FG1, ... bzw. FGN eingestellten MLFB generiert 
wird. 
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Als Unterscheidungsmerkmal zwischen diesen beiden Dateifor- 
men, namlich den statischen Dateien und den Dateien mit dyna- 
mischen Daten, dient ein Eintrag in einer Datei „noca- 
che.txt w . Alle dynamisch in den Feldgeraten FG1...FGN er- 
zeugten Dateien miissen in dieser Datei aufgefuhrt sein. Sta- 
tische Dateien werden vom HTTP-Server HS1...HSN der Feldgera- 
te FG1..-.FGN mit einer unendlichen Lebensdauer gekennzeich- 
net. Im folgenden ist ein Beispiel fur den Inhalt der Datei 
„ nocache . txt w gezeigt : 

/mlfb.txt: MLFB, BF-Nr . , Displaytyp 

/textpool.zip: geratespezif ische Texte fur Applets 

( mehr sprachig ) 

/ver.txt: Version, Datum 

/chartab . j ar : Geratezeichensat z 

Die Datei „ver.txt" kann hierbei den' folgenden Inhalt aufwei- 
sen/anzeigen : 

VOL 01.01 

Tue, 24 Oct 2000 07:50:00 GMT 
Slot-Protokoll des Proxy servers 

Das Slot-Protokoll 4 8 (vgl. Figur 8) dient der Anbindung des 
Proxyservers 1 an die Feldgerate FG1...FGN in einer Anordnimg 
mit Sternkoppler nach Figur 7. Das Slot-Protokoll 48 glie- 
dert sich in die beiden Bereiche (i) Gerateerkennung und (ii) 
Arbitierung der Sternkoppleranordnung. Die Gerateerkennung 
dient der automatischen Erkennung aller an den Sternkoppler 
3 9 angescblossenen Feldgerate FG1...FGN. Die Arbitierung 
muss Kollisionen von Datagrammen unterschiedlicher Feldgerate 
FG1...FGN auf der Kommunikationsverbindung zwischen dem Pro- 
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xyserver 1 und den einzelnen Feldgeraten FG1...FGN verhin- 
dern. 

Im folgenden wird die Gerateerkennung bei Nutzung der Stern- 
5 koppleranordnung 3 9 beschrieben . 

Gerateerkennung ' 

Die Gerateerkennung stellt einen Bestandteil des Slot- 
10 Protokolls 48 dar. Dieser Protokollteil belegt die serielle 
Verbindung exklusiv, d. h. wahrend der Gerateerkennung darf 
keine andere Kommunikation auf der Modems trecke aktiv sein. 
Deshalb wird die Gerateerkennung nur beim Aufbau der Modem- 
verbindung aktiviert. Im laufenden Betrieb des Beobachtungs- 
15 und Bediensystems ist dieser Protokollteil inaktiv. Die Ge- 
rateerkennung kann jedoch bei Bedarf aktiviert werden. 

Figur 10 zeigt eine Master- Slave -Anordnung mit Sternkoppler 
zur Erlauterung der Gerateerkennung. 

Das Slot-Protokoll 48 arbeitet nach dem Master-Slave- Prinzip . 
Ein Master 70 befindet sich am oberen Anschluss in Figur 10. 
Die unteren Anschliisse eines Sternkopplers 71, welcher dem 
Sternkoppler 3 in Figur 1 entspricht, werden von jeweils ei- 
nem Slave S1...SN belegt, welche den Feldgeraten FG1...FGN 
gemafi Figur 1 entsprechen. Der Master 70 konnte jede mogli- 
che Adresse der angeschlossenen Slaves S1...SN abfragen und 
bei einer Antwort auf diese Anfrage den gefundenen Slave SI, 
. . . bzw. SN in die Liste der Gerate aufnehmen, die dem Master 
70 bekannt sind. Diese Vorgehensweise ist jedoch bei : einem 
Adressbereich von 32 Bit nicht mehr durchf uhrbar . Hier waren 
2^32 Abfragen erf orderlich. Diese Zahl ist jedoch nicht mehr 
durchfuhrbar, da hier die fur diese Abfrage erf orderliche 
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Zeit die Lebensdauer der Anlage uberschreiten wurde. Um den- 
noch die an den Master 7 0 angeschlossenen Gerate automat isch 
erkennen zu konnen, wird das Problem erf indungsgemaS in der 
folgenden Weise gelost: 

Bei einem Adressierungs schema mit einer Binar kodierten Ad- 
resse mit einer fest vorgegebenen Adresslange wird bei einer 
Anf rage immer ein Adressbereich abgef ragt . Auf diese Anf rage 
antworten nur die Slaves, die sich in dem abgef ragten Adress- 
bereich befinden. Da sich hier mehrere Feldgerate (Slaves) 
im gleichen abgefragten Adressbereich befinden konnen, kommt 
es bei einer gleichzeitigen Antwort von mehreren der Slaves 
S1...SN in diesem Fall zwangslaufig zu einer Kollision. Die- 
se Kollision wird bewusst in Kauf genommen und ist Bestand- 
teil des vorgeschlagenen Verfahrens. Aus diesem Grund priift 
der Master 70 nur, ob innerhalb eines definierten Zeitraums 
uberhaupt eine Antwort auf seine Anf rage eingegangen ist. 

Betragt der Adressraum der adressierbaren Slaves S1...SN n 
Bits, sendet der Master 70 jeweils eine Anf rage mit einem 
f eststehenden Bit der Adresse und einer Maske fur die anderen 
Adressbits aus. Mit zwei Abfragen kann getestet werden, ob 
sich in dem durch das feststehende Bit vorgegebenen Adressbe- 
reich Slaves befinden. Wurde auf eine Anf rage fur einen Ad- 
ressbereich eine Antwort erhalten, dann wird die Maske um ein 
Bit verkleinert und fur das nachste feststehende Bit mit wie- 
derum zwei Abfragen getestet, ob sich in dem nun kleineren 
Adressbereich Slaves befinden. Kommt auf die Anf rage fur den 
nun kleineren Adressbereich eine Antwort, dann ist das nachs- 
te Bit des Adressbereichs gefunden, in dem sich Slaves befin- 
den. Dieser Vorgang wird so lange wiederholt, bis die Maske 
fur den Adressbereich sich auf 0 Bits reduziert hat. Dann 
ist einer der Slaves S1...SN am Bus eindeutig identif iziert . 
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Kommen bei einer Abfrage auf beide Zustande des gerade getes- 
teten Bits Antworten, dann werden beide Zweige in der nachs- 
ten Iteration weiter verfolgt. Da bei einer MaskengroSe von 
0 Bits nur das Gerat bzw. der Slave mit der angefragten, nun 
vollstandig f eststehenden Adresse auf die gestellte Anfrage 
antworten kann, konnen bei der letzten Anfrage auch keine 
Kollisionen mehr auftreten, und das Antworttelegramm der zu 
detektierenden Slaves kann spontane Inf ormationen uber den 
Zustand der angeschlossenen Slaves enthalten. Figur 12 erlau- 
tert das beschriebene Verfahren noch einmal anhand eines ein- 
fachen Adre s s i erungs s chemas mit einer 4 -Bit Adresse, also fur 
einen Adressraum vom 0 bis 15. Es wird vorausgesetzt, dass 
sich die Gerate mit den Adressen 3, 4 und 7 in der Anordnung 
befinden. Es wird mit der Abfrage vom hochstwertigen Bit be- 
gonnen. Es wird also zum einen der Adressraum 0 bis 7 und in 
einer zweiten Abfrage der Adressraum 8 bis 15 mit einer Ab- 
frage getestet. Auf diese zweite Abfrage antwortet kein Ge- 
rat. Auf die erste Abfrage erhalt der Master eine oder mehre- 
re Antworten. Deshalb wird im Adressraum 0 bis 7 die Maske urn 
ein weiteres Bit verkleinert . Es werden also nun die Adress- 
bereiche 0 bis 3 mit einer dritten Abfrage und 4 bis 7 mit 
einer vierten Abfrage gepriift. Dieser Vorgang wiederholt sich 
entsprechend der Darstellung in Fig. 12 so lange, bis die Ad- 
ressen vollstandig aufgelost und damit alle Gerate gefunden 
sind. 

In dem beschriebenen Beispiel werden die Slaves Sl...Sn bzw. 
die Feldgerate FG1...FGN mittels eines IP-basierten Proto- 
kolls an den Master 70 angeschlossen. Beim IP-Protokoll ha- 
ben alle Busteilnehmer eine 32 Bit-Adresse. Die Adresse wird 
in Oktette aufgeteilt. und jedes Oktett dezimal dargestellt. 
Die hexadezimale 32 Bit-Zahl 0x8D8D8000 entspricht also der 
IP-Adresse 141.141.128.0. Fur den eigentlichen Vorgang zur 
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Gerateerkennung/-abfrage wird eine rekursive Variante des im 
vorhergehenden Absatz beschriebenen Verfahrens verwendet. 

Figur 11 zeigt das Ablaufdiagramm des Verfahrens als Nassi- 
5 Sneidermann-Diagramm. 

Im Rahmen des beschriebenen Verfahrens wird der Test, ob ein 
Feldgerat (Slave) im verfugbaren Adressbereich ansprechbar 
1st, vorzugsweise mit Hilfe eines als solchen bekannten Re- 
10 quest -Datagramms vom Master 70 ausgelost. ' Im Unterschied zu 
herkommlichen Verfahren wird jedoch bewusst in Kauf genommen, 
dass auf ein vom Master 70 ausgesandtes Request-Datagramm 
mehrere der Slaves S1...SN gleichzeitig antworten. Dadurch, 
dass im Stemkoppler 71 alle von den Slaves S1...SN empfange- 
nen Signale iiber ein logisches ODER-Gatter verkniipf t werden 
und dieses Summensignal an den Master 70 weitergeleitet wird, 
kann sichergestellt werden, dass im Master 70 eine Antwort 
eines der Slaves S1...SN in jedem Fall erkannt wird. Wenn 
sich die Antwort -Datagramme mehrerer der Slaves S1...SN zeit- 
lich uberlappen, wird im Master 70 ein fehlerhaftes Datagramm 
empfangen. Auch dieser Fall wird als Antwort erkannt. 

Mit Hilfe der Vorgabe einer maximalen Antwortzeit fur die 
Slaves S1...SN auf ein Request-Datagramm des Masters 70 und 
der Datagramm-Ubertragungszeit kann eine Uberwachungszeit fur 
den Master 70 definiert werden. Erhalt der Master 70 inner- 
halb dieser Uberwachungszeit eine Antwort, dann befinden sich 
im angefragten Adressbereich Slaves bzw. Feldgerate. Im Um- 
kehrschluss befinden sich im angefragten Adressbereich keine 
Feldgerate, wenn vom Master 70 innerhalb der Uberwachungszeit 
keine Antwort auf den Request empfangen wurde. 
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Da bei einer vollstandigen Auflosung der Adresse im Request 
. des Maters 70 (d.h. die Maske wird leer) nur noch einer der 
Slaves S1...SN antworten darf, kann in diesem Fall auch keine 
Kollision mehr auftreten. Damit kann in diesem Fall die Feh- 
5 lersicherung des empf angenen Datagramms benutzt werden, urn 
eine Leitungsstorung und damit eine mdgliche Fehlerkennung 
eines angeschlossenen Slaves auszuschliefien. Tritt wahrend 
der Uberwachungszeit nach einem Request des Masters eine Lei- 
, tungsstorung auf , die einen nicht vorhandenen Slave vor- 

10 tauscht , fiihrt das nur zu einer Verlangerung des Vorgangs zum 
Abfragen, aber nicht zu einer falschen Erkennung von ange- 
schlossenen Slaves, da diese Leitungsstorung spatestens bei 
der vollstandigen Auflosung der Maske erkannt wird. 
Der folgende Absatz zeigt anhand eines Beispiels die Funktion 

15 des Verf ahrens : 



Test : 


141. 


141. 


128.0 


Mask: 


255 


.255 


.128 


. 0 


Test : 


141. 


141. 


0 . 


0 


Mask: 


255 


.255 


.128 


.0 


Test : 


141. 


141. 


64 


. 0 


Mask: 


255 


.255 


.192 


.0 


Test : 


141. 


141. 
i 


96 


.0 


Mask: 


255 


.255 


.224 


.0 


Test : 


141. 


141. 


64 


. 0 


Mask: 


255 


.255 


.224 


.0 


Test : 


141. 


141. 


80 


.0 


Mask: 


255 


.255 


.240 


.0 


Test : 


141. 


141. 


88 


.0 


Mask: 


255 


.255 


.248 


.0 


Test : 


141. 


141. 


80 


.0 


Mask: 


255 


.255 


.248 


.0 


Test : 


141. 


141. 


84 


.0 


Mask: 


255 


.255 


.252 


.0 


Test : 


141 . 


141. 


86 


. 0 


Mask: 


255 


. 255 


.254 


. 0 


Test : 


141. 


141. 


84 


. 0 


Mask: 


255 


.255 


.254 


. 0 


Test : 


141. 


141. 


85 


. 0 


Mask: 


255 


.255 


.255 


. 0 


Test : 


141. 


141. 


84 


.0 


Mask: 


255 


.255 


.255 


.0 


Test : 


141. 


141. 


84 


.128 


Mask: 


255 


. 255 


.255 


.128 


Test : 


141. 


141. 


84 


.0 


Mask: 


255 


.255 


.255 


.128 


Test : 


141 . 


141. 


84 


.64 


Mask: 


255 


.255 


.255 


.192 


Test: 


141. 


141. 


84 


.0 


Mask: 


255 


.255 


.255 


.192 


Test : 


141. 


141. 


84 


.32 


Mask: 


255 


.255 


.255 


.224 
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Test: 141.141.84.0 
Test: 141.141.84.16 



Test : 


141 


.141 


.84 


.0 


Test : 


141 


.141 


. 84 


.8 


Test : 


141 


. 141 


.84 


.0 


Test : 


141 


.141 


.84 


.4 


Test : 


141 


. 141 


.84 


. 0 


Test : 


141 


.141 


.84 


.2 


Test : 


141 


.141 


. 84 


.3 


Test : 


141 


.141 


.84 


.2 


Found: 


141 


.141 


.84 


.2 


Test : 


141 


.141 


.84 


.0 


Test : 


141 


.141 


.80 


.0 


Test : 


141 


.141 


.82 


.0 


Test : 


141 


.141 


, 80 


. 0 


Test : 


141 


.141. 


. 81 


. 0 


Test : 


141 


.141. 


.80 


.0 


Test : 


141 . 


.141. 


. 80 . 


. 128 


Test : 


141 . 


.141. 


. 80 . 


.192 


Test : 


141 . 


.141. 


80. 


, 128 


Test : 


141 . 


.141. 


80 . 


160 


Test : 


141 . 


141 . 


80. 


176 


Test : 


141 . 


141. 


80 . 


160 


Test : 


141. 


141. 


80. 


168 


Test : 


141. 


141. 


80 . 


160 


Test: 


141 . 


141. 


80. 


164 


Test : 


141 . 


141. 


80 . 


166 


Test : 


141. 


141. 


80. 


164 


Test : 


141. 


141. 


80 . 


165 


Test : 


141 . 


141. 


80. 


164 


Found: 


141. 


141. 


80 . 


164 


Test : 


141 . 


141. 


80. 


160 


Test : 


141. 


141. 


80. 


162 
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Mask: 255 . 255 . 255 . 224 
Mask: 255.255.255.240 
Mask: 255 .255 .255 .24 0 
Mask: 255.255.255.248 
Mask: 255 .255 .255 .248 
Mask: 255.255.255.252 
Mask : 255 .255.255. 252 
Mask: 255.255.255.254 
Mask: 255.255.255.255 
Mask: 255.255.255.255 

Mask: 255.255.255.254 
Mask: 255.255.252.0 
Mask: 255.255.254.0 
Mask: 255.255.254.0 
Mask: 255.255.255.0 
Mask: 255.255.255.0 
Mask: 255 .255 . 255 . 12 8 
Mask: 255 .255 . 255 . 192 
Mask: 255 . 255 . 255 . 192 
Mask: 255 . 255 . 255 .224 
Mask : 255 . 255 . 255 . 240 
Mask: 255.255.255.240 
Mask: 255 . 255 . 255 . 248 
Mask: 255 .255 . 255 .248 
Mask: 255.255. 255 .252 
Mask: 255 . 255 . 255 . 254 
Mask: 255.255.255.254 
Mask: 255.255.255 .255 
Mask: 255.255.255.2 55 

Mask: 255.255.255.252 
Mask: 255.255.2 55.2 54 
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Test : 


141 . 


141 . 


80 


. 163 


Mask: 


255 


. 255 


. 255 


*-j r* P" 

. 255 


Found : 


141 . 


141 . 


80 


. 163 












Test : 


141 . 


141 . 


80 


. 162 


Mask : 


255 


n r r 

. 255 


ore 

. 255 


o c c 


Test : 


141 . 


141 . 


80 


. 160 


Mask: 


255 


rv r r 

. 255 


r> r r 

. 255 


. 254 


Test : 


141 . 


141 . 


80 


. 161 


Mask : 


255 


. 255 


O r r 

.255 


o c c 


Found: 


141 . 


141 . 


80 


. 161 












Test : 


141 . 


141 . 


80 


. 160 


Mask : 


OTP 

255 


. 255 


or r 

. 25b 


o c c 


Found : 


141. 


141. 


80 


.160 












Test : 


141. 


141. 


80 


.128 


Mask : 


255 


.255 


.255 


.224 


Test : 


141. 


141. 


80 


.0 


Mask: 


255 


.255 


.255 


.128 


Test : 


141 1 


141. 


64 


.0 


Mask: 


255 


.255 


.240 


.0 


Test : 


141. 


141 . 


0 . 


0 


Mask: 


255 


.255 


.192 


.0 


58 Abfragen . . . 

















15 Die Abfragen schlossen den Adressraum 141. .141. 0.0 bis 

141.141.255.255 ein. Es wurden die Gerate mit den folgenden 

Adressen gefunden: 

141.141.84.2 

141.141.80.164 : 

141.141.80.163 

141.141.80.161 

141.141.80.160 

Figur 12 illustriert den dargestellten Vorgang in Form einer 
2 0 Baumdarstellung, wobei die fett umrandeten Felder die Abfra- 
gen kennzeichnen, die von einem oder mehreren Slaves ' SI ... SN 
bzw. Feldgeraten beantwortet wurden. 

Broadcast -Dienst 

25 

Fur die Anbindung des Proxyservers 1 an die Feldgerate 
FG1...FGN kann anstelle der einfachen Architektur mit Stern - 
koppler 39 ein IP-basiertes Netzwerk genutzt werden. In die- 
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sem Fall ist eine Arbitierung dieses Netzwerks durch ein Pro- 
tokoll, beispielsweise das Slot-Protokoll 48, nicht erforder- 
lich. Diese Funktion ubernimmt das Netzwerk selbst. Fur die 
Gerateerkennung kSnnen bei dieser Ausf uhrungsf orm ebenfalls 
Funktionen des Netzwerks genutzt werden. Bei einer Netzwerk- 
verbindung zwischen dem Proxyserver 1 und den Feldgeraten 
FG1...FGN wird zur Selbstkbnf igurierung des Beobachtungs- und 
Bediensystems ein Broadcast-Dienst benutzt. 

In beiden Fallen des Erkennens der angeschlossenen Feldgerate 
FG1...FGN, d.h. bei der Ausf uhrungsf orm mit Sternkoppleran- 
ordnung und bei Nutzung eines Netzwerks, insbesondere eines 
LANs , wird das Erkennen bei Inbetriebsetzung des Beobach- . 
tungs- und Bediensystems automat isch ausgefuhrt und erfolgt 
ohne vorherige Parametrierung der am System beteiligten Kom- 
ponenten. &a 

Der Broadcast-Dienst dient jzum Erkennen der an das IP- 
basierte Netzwerk (z. B. LAN) angeschlossenen Feldgerate, die 
einen Server fur ihre eigene Bedienung enthalten. Weiterhin 
dient der Broadcast-Dienst zum Einsammeln von in den ange- 
schlossenen Feldgeraten auf getretenen spontanen Ereignissen. 
Der Broadcast-Dienst ist eine IP-Applikation und basiert so- 
mit auf den Funktionen des IP-Stacks und setzt auf dem UDP- 
Protokoll auf. Fur diesen Dienst wird Serverseitig z. B. ein 
fest vorgegebener Port OxDOOO reserviert. Clientseitig wird 
dynamisch ein freier Port ausgewahlt . Durch den Einsatz des 
Standard-UDP/IP-Protokolls kann hier auf den IP-Programmier- 
schnittstellen von lib lichen Betriebssystemen, wie z. B. MS- 
Windows oder Linux, aufgesetzt werden. Damit kann der Proxy- 
server 1 problemlos auf klassische Buroserver portiert wer- 
den. 
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Der Broadcast -Dienst ist sowohl im Proxyserver 1 als auch in 
den einzelnen Feldgeraten aktiv. Fur den Broadcast -Dienst 
wird der Proxyserver 1 als Master f estgelegt . Eine Konf igu- 
rationsabf rage ist ein vom Master abgesendetes UDP-Telegramm 
Dieses Telegramm richtet sich je nach Konf igurat ion an eine 
Broadcast- oder eine Multicast-IP-Adresse . Eine Beschreibung 
von Broadcast- oder Multicast- IP- Adressen findet sich bei- 
spielsweise in Karanjit S. Siyan: Inside TCP/IP Third Editi- 
on, New Riders Publishing, Indianapolis, 1997, ISBN 1-56205- 
714-6, Seite 187ff. 

Alle Feldgerate werden anschlieSend auf die Konf igurationsab 
frage des Masters mit einem UDP-Telegramm antworten, welches 
die wichtigsten Konf igurat ionsdat en des Feldgerats enthalt. 
Da jetzt alle an dem IP-basierten Netzwerk angeschlossenen 
Feldgerate theoretisch gleichzeitig Antworten mochten, wird 
es zunachst zu einigen Kollisionen auf dem genutzten Bus kom- 
men, die durch das CSMA/CD-Verf ahren (CSAM - „ carrier sense, 
multiple access/collision detect") aufgelost werden. Eine 
Beschreibung dieses Verfahrens ist ebenfalls in Karanjit S. 
Siyan: Inside TCP/IP Third Edition, New Riders Publishing, 
Indianapolis, 1997, ISBN 1-56205-714-6, Seite 97ff, zu fin- 
den. Die UDP-Antworttelegramme aller aktiven Feldgerate wer- 
den also beim abfragenden Master ihnerhalb einer gewissen 
Zeit ankommen. Somit ist der Abfragende in der Lage festzu- 
stellen, wie viele und welche Feldgerate sich im Netzwerk be- 
finden, und kann anschlieSend von den Feldgeraten weitere In- 
formationen uber das HTTP- Pro tokoll oder andere IP-basierte 
Protokolle anfordern. 

Der Broadcast-Dienst hat aufierdem noch die Aufgabe, ein spon- 
tan in einem der Feldgerate auflaufendes Ereignis im IP- 
basierten Netzwerk an die Teilnehmer des Broadcast-Dienstes 
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zu yerteilen. Da die Feldgerate einerseits keine Information 
daruber besitzen, welcher Master fur dieses Signal zustandig 
ist und es andererseits moglich sein kann, das im IP- 
basierten Netzwerk mehrere Master mit verteilten Aufgaben e- 
xistieren, wird das Ereignistelegramm als Broadcast an alle 
Netzwerkteilnehmer gesendet. Die Master konnen dieses Signal 
je nach Ereignistyp und Sender ignorieren oder eine Aktion 
auslosen, welche uber ein weiteres Protokoll, z. B. HTTP, zu- 
satzliche Inf ormationen von dem Feldgerat abruf t . Dieses Ab- 
rufen zusatzlicher Inf ormationen am das Ereignis aussendenden 
Feldgerat durch den zustandigen Master dient gleichzeitig als 
Empf angsbestatigung des Masters. Wird ein Ereignistelegramm 
nicht bestatigt, dann wird es solange in regelmaSigen Abstan- 
den (beispielsweise etwa 10 s oder mit einer logarithmisch 
wachsenden Zeit) wiederholt bis eine Bestatigung von einem 
Master stattfindet. 

Figur 13 zeigt eine schematische Darstellung zur Erlauterung 
des Verfahrens im Rahmen der Konf igurationsabf rage . 

Der Proxyserver 1 sendet als Master eine Konf igurationsanf ra- 
ge 72 als Broadcast an alle Teilnehmer im Netzwerk. Alle 
Feldgerate FG1...FGN antworten mit einem UDP-Datagramm an die 
IP-Adresse des Masters, der die Konf igurationsanf rage ausge- 
sandt hat. Dieses UDP-Datagramm enthalt wie bereits darge- 
stellt die wichtigsten Inf ormationen uber die angeschlossenen 
Gerate. 

Gerateverwaltung 

Die Verwaltung der mit Hilfe der Gerateerkennung bei Nutziang 
des Sternkopplers 3 9 oder des Broadcast -Dienstes erkannten 
Feldgerate bzw. Slaves erfolgt im Proxyserver 1 mit Hilfe der 
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Gerateverwaltung 49 (vgl . Figur 8) . Figur 14 zeigt ein sche- 
matisches Blockdiagramm der Anbindung der Gerateverwaltung 49 
im Proxyserver 1. 

5 Die Gerateverwaltung 49 stellt der Cacheverwaltung 43 und der 
XML-Datenbank 50 Inf ormationen uber die im Geratenetzwerk er- • 
kannten Feldgerate FG1...FGN zur Verfugung. Dazu bezieht die 
. Gerateverwaltung 49 ihre Inf ormationen iiber die angeschlosse- 
- nen Feldgerate FG1 . . . FGN aus dem im Rahmen des Slot- 

10 : Protokolls 48 ablaufenden Verfahrens. Auf diese Weise werden 
die IP-Adressen der angeschlossenen Feldgerate FG1...FGN be- 
reitgestellt . Die Gerateverwaltung 49 wird vom Slot- 
Protokoll 4 8 mit den Inf ormationen uber die erkannten Feldge- 
rate FG1...FGN versorgt . Das Slot-Protokoll 48 liefert der 

15 Gerateverwaltung 49 nur die IP-Adressen der erkannten Feldge- 
rate FG1...FGN. Alle weiteren Inf ormationen iiber die Feldge- 
rate FG1...FGN, die durch die Gerateverwaltung 49 im Proxy- 
server 1 bereitzustellen sind, werden mit des Herunterladens 
von HTTP-Daten in festgelegten Dateien aus den Feldgerate 

20 FG1...FGN beschafft. Die Gerateverwaltung 49 stellt mit Hil- 
fe der bekannten IP-Adressen aller erkannten Feldgerate 
FG1 . . . FGN der Cacheverwaltung 43 die folgenden Inf ormationen 
uber die Feldgerate FG1...FGN zur Verfiigung: Feldgerate-Typ, 
Feldgerate -Version und Version des Dateiblocks fur das Beo- 

25 bachtungs- und Bediensystem. 

Im Dateicache 45 (vgl. Figur 8) sind diese Inf ormationen fur 
die dort bereits gespeicherten Dateien ebenfalls vorhanden. 
Damit kann bei einer Anforderung einer Datei von einem be- 
3 0 stimmten der Feldgerate FG1...FGN anhand dieser Inf ormationen 
entschieden werden, ob die im Dateicache 45 vorliegende Datei 
mit der in dem Feldgerat verfiigbaren Datei identisch ist, oh- 
ne den Dateikopf der angef orderten Datei aus dem bestimmten 
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Feldgerat zu lesen. Es mussen nur die im Dateicache 45 vor- 
liegenden Versionsinf ormationen fur die Datei mit den Infor- 
mationen aus der Gerateverwaltung 49 fur die IP-Adresse des 
bestimmten Feldgerats verglichen werden. 

Die Anbindung der Gerateverwaltung 49 an die XML - Da t enbank 50 
dient der Bereitstellung von Inf ormationen aus den Feldgera- 
ten FG1...FGN. Diese Inf ormationen werden in Form einer XML- 
Datei aus den Feldgeraten FG1 . . . FGN geladen. Die folgende 
Tabelle zeigt eine Ubersicht liber die Inhalte dieser Datei : 



Information 


J. cty 




Geratetyp 


DEV_TYPE 


Stellen 1..6 der MLFB 


MLFB 


MLFB 


vollstandige MLFB des Gerates 


BF-Nummer 




Q€*Tr?k t* ^Icf^Trni ma ( nnimip nuinber tt ) 


Ver- 




VER_KEYS 


Liste von Versionsschlusseln 


sion 


Datei - 
system 


VERSION 


Datum und Versionsnummer des Da- 
teisystems 




Firmwa- 
re 


VERSION 


Datum und Versionsnummer der Gera- 
tef irmware 




System- 
firmwa- 
re 


VERSION 


Datum und Versionsnummer der im 
Gerat verwendeten Systemf irmware 


„non ca- 
cheable" Da- 
teien 


NOCACHE 


Liste aller Dateien, die immer di- 
rekt vom Gerat geholt werden mus- 
sen 


Menubaum 


MENU 


Geratebedienbaum zur Einbettung in 
den Proxyserver-Bedienbaum 


Prozessdaten 


DATA_OBJ 


Liste der XML-Dateien, die alle 
vom Gerat lieferbaren Prozessdaten 
beschreiben 
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Alle diese Inf ormationen werden in einer Datei w DevData.xml w 
gespeichert. Die Gerateverwaltung 49 veranlasst ein HTTP- 
Herunter laden dieser Datei, wenn eines der Feldgerate 
FG1 . . - FGN vom Slot-Protokoll 48 gefunden wurde. Alle weite- 
5 ren Dateien werden von der Gerateverwaltung 4 9 nur dann aus 
dem Feldgerat geladen, wenn deren Dateipfad in dieser XML- 
Datei enthalten ist, d.h. es werden alle mit einem 
• <DEV__PATH> - Tag gekapselten Dateien geladen. 

10 ; Die Datei „DevData.xml w wird im Proxyserver 1 nach dem Herun- 
terladen mit Hilfe des XSL-Parsers 54 in das interne Format 
des Proxyservers 1 trans formiert und anschliefiend in der XML- 
Datenbank 5 0 des Proxyservers 1 eingetragen. 

15 XSL-Parser 

Der XSL-Parser 54 (vgl . Figur 8) dient der Erzeugung von dy- 
namisch generierten HTML -Dateien aus der zentralen XML- 
Datenbank 5 0 des Proxyservers 1. Dazu werden lokal im Proxy - 
20 server 1 abgelegte XSL-Scripte benutzt. Die XSL-Scripte kon- 
nen mit Hilfe einer Admin-Seite in den Proxyserver 1 einge- 
spielt werden. 

Figur 15 zeigt die Einbindung des XSL-Parsers 54 in dem Pro- 
25 xyserver 1. 

Wird uber den HTTP-Server 40 eine XMl-Datei von den Nutzer- 
einrichtungen Nl . . .NN aus dem Intranet angefordert, dann wird 
diese Anforderung vom Datei-Filter 42 ausgefiltert und an das 
30 XML-Front-end HTTP 55 weitergeleitet . Dieses Front-end sucht 
eine zur angef orderten XML-Datei gehoriges XSL- 
Trans formations script und startet den XSL-Parser 54 mit die- 
sen beiden Dateien. 
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Da dynatnisch generierte HTML-Seiten die verwendeten Daten im- 
mer aus der lokal im Proxyserver 1 liegenden XML-Datenbank 50 
verwenderi; muss der Inhalt dieser Datenbank mit den in den 
5 Geraten vorhandenen Daten abgeglichen werden. Dieser Ab- 

gleichprozess ist deshalb erf orderlich, da viele in der XML- 
Datenbank 50 abgelegen Daten wie z. B. Messwerte zeitveran- 
derlich sind. Diesen Abgleich ubernimmt der Block XML-Front- 
end RPC-Cache 57. Bei einem Zugriff vom XSL-Parser 54 auf die 

10 XML-Datenbank 50 wird vom zwischengeschalteten XML - Front - end 
57 die Gultigkeitsdauer der angef orderten Information uber- 
pruft. Ist die angef orderte Information bereits ungultig ge- 
worden, dann wird sie von der Verbindungsverwaltung 52 neu 
aus dem RPC-Client 53 aus dem Gerat angefordert, in der XML- 

15 Datenbank 50 aktualisiert und an den XSL-Parser 54 weiterge- 
leitet . 

Die Gerat everwaltung 49 uberwacht fortlaufend den Status der 
am Geratenetzwerk angeschlossenen Gerate und aktualisiert 
diese Inf ormationen mittels des XML-Front-end Geratedaten 56 
20 in der XML-Datenbank 50. 

Der XSL-Parser 54 ist das Hauptbindeglied bei der Darstellung 
der aktuellen, von den Feldgeraten FG1...FGN empfangenen Da- 
ten aus der XML-Datenbank 50. Jedes XSL-Script gibt Trans- 

25 formationsregeln vor, die festlegen, in welcher Weise be- 
st immte Daten aus der XML-Datenbank 50 in Form von HTML- 
Seiten in den Nutzereinrichtungen N1...NN anzuzeigen sind. 
Eines der Grundprinzipien von XML ist die Trennung von Inhalt 
und Presentation. Ein XML-Dokument enthalt nur "Inhalt" , sei- 

3 0 ne Presentation muss, in Form eines Stylesheets, gesondert 

definiert werden. Es gibt verschiedene Moglichkeiten die Dar- 
stellungsinf ormation zu einem XML-Dokument hinzuzuf ugen . Die- 
se beruhenauf zwei Grundverf ahren : Entweder wird das Doku- 
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meat gemaS eines Stylesheets in eine darstellbare Form ge- 
bracht oder das Stylesheet leitet den Darstellungsmechanismus 
dabei an, wie die einzelnen Element e des Dokument s darzustel- 
len sind. Diese beiden Grundverf ahren konnen in verschiedener 
Weise variiert werden: 

- CSS-Stylesheet + XML-Dokument — > XML-f ahiger Browser 

Der Browser verarbeitet das Dokument und die Darstellungs- 
informationen in Form eines CSS-Stylesheets und erzeugt 
eine Presentation . 

- XSL-Stylesheet + XML-Dokument -» XSL-f ahiges Darstellungs- 
programm 

Ein Darstellungsprogramm, das XSL-Stylesheets verarbeiten 
kann, erhalt neben dem Dokument die Prasen- 
tationsinf ormation in Form eines XSL-Stylesheets. 
_ XSL-Stylesheet + XML-Dokument -> XSL-Transf ormator -> HTML- 
Dokument 

Das XML-Dokument wird entsprechend der Trans f ormationsre- 
geln eines XSL-Stylesheets von einem XSL-Transf ormator in 
ein (X)HTML-Dokument transf ormiert , das dann von einem 
Browser dargestellt werden kann, 

Figur 16 zeigt ein schematisches Blockschaltbild eines XSLT- 
Prozessors (XSL - „ Extended Stylesheet Language Transf ormati- 
on") . 

Das in Figur 16 dargestellte Blockschaltbild verdeutlicht 
noch einmal den Datenfluss, wenn eine XML-Datei angefordert 
wird. Die vom Client angeforderte Datei Xview.XML wird vom 
HTTP-server an den XSLT-Prozessor 54 weitergeleitet . Dieser 
sucht die zur angefordert en Datei Xview.XSL gehorige Datei 
Xview.XSL und startet den XSLT-Prozessor 54 mit diesen beiden 
Dateien. Soli in dem liber die angeforderte Datei Xview.XML 
gestarteten Transformationsprozess Prozessdaten aus der XML- 
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Datenbank 50 des Proxyservers verwendet werden, dann muss das 
Transformationsscript Xview.XSL einen Verweis auf diese Da- 
tenbank enthalten. In dem in Figur 16 dargestellten Beispiel 
hat diese XML-Datenbank 50 den Namen Siprogate .XML.. 

5 

Da alle mit Hilfe der Nutzereinrichtungen N1...NN angezeigten 
Informationen bei ihrer Anforderung einen XSLT-Prozessor 
durchlaufen, ist es zweckmafiig, die hierbei angef orderten In- 
formationen wie bereits beschrieben mit Hilfe des XML-Front - 

10 ends RPC-Cache 57 auf ihre Giiltigkeit zu prufen und das Re- 
sult at fur einen Aktualisierungsmechanismus zu verwenden. 
Hierzu muss der XSLT-Parser so manipuliert werden, dass fest- 
gestellt werden kann, welche Daten aus den einzelnen Daten - 
banken bei der Gestaltung der zu erzeugenden HTML-Seite be- 

15 teiligt sind. Anhand dieser Information wird dann in einem 
zweiten Schritt f estgestellt , ob diese Daten aktuell sind. 
Daraufhin werden die dazu erf orderlichen Aktualisierungsme- 
chanismen angestoSen, sofern dies notwendig ist, und im An- 
schluss der Parservorgang noch einmal gestartet, wobei immer 

20 nur jene Daten aktualisiert werden, die gegenwartig in jegli- 
cher Form einem Benutzer mit Hilfe einer oder mehrerer der 
Nutzereinrichtungen N1...NN angezeigt werden. Das wird da- 
durch erreicht, dass nur die angef orderten Daten in der XML- 
Datenbank aktualisiert werden. Aufgrund der moglicherweise 

25 erheblichen GesamtgroSe der XML-Datenbank 50 ergibt sich mit 
Hilfe dieses Mechanismus eine Reduzierung der zwischen den 
Feldgeraten FG1 . . . FGN und dem Proxyserver 1 ubertragenen Da- 
ten, da einerseits nur auf Anforderung und andererseits immer 
nur die fur die jeweilige Darstellung erf orderlichen Daten 

3 0 geholt werden. 
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Patentanspruche 

1. Verfahren zur Inbetriebnahme eines Bedien- unci Beobachtungs- 
systems fur Feldgerate (N1...NN), wobei in den Feldgeraten 
5 (N1...NN) jeweils eine Servereinrichtung ausgebildet ist und 

die Feldgerate (FG1...FGN) an eine Proxy- Servereinrichtung (1) 
angeschlossen sind und wobei die Proxy- Servereinrichtung (1) 
mit einer Nutzereinrichtung (Nl, NN) verbunden ist, auf 

welcher eine Brows er-Einrichtung installiert ist, das Verfah- 
10 ren die folgenden Schritte aufweipend: 

- Ausfuhren einer Abfrage der Feldgerate (FG1...FGN) durch 
die Proxy-Servereinrichtung (1) zum automat ischen Erkennen 
der an die Proxy-Servereinrichtung (1) angeschlossenen 
Feldgerate (FG1 . . . FGN) ; 
15 - Erfassen einer jeweiligen Netzwerkadresse fur die Feldgera- 

te (FG1...FGN) durch die Proxy-Servereinrichtung (1); und 
Erzeugen einer Basis information durch die Proxy-Server- 
einrichtung (1) , wobei die Basisinf ormation in Abhangigkeit 
von der Abfrage der Feldgerate (FG1...FGN) jeweilige elekt- 
20 ronische Inf ormationen iiber die Feldgerate (FG1...FGN) um- 

fasst und wobei die jeweiligen elektronischen Inf ormationen 
eine Link- Information auf die jeweilige Servereinrichtung 
der Feldgerate (FG1...FGN) umfassen. 

25 2. Verfahren nach Anspruch 1 # 

dadurch gekennzeichnet, dass 

die Link- Information ausgebildet ist, so dass nach einem Uber- 

mitteln der Basisinf ormation an die Nutzereinrichtung (Nl, 

NN) mit Hilfe der Browser-Einrichtung jeweilige Geratein- 

3 0 f ormationen zum Beobachten/Bedienen der Feldgerate (FG1...FGN) 

grafisch ausgegeben werden, die von der jeweiligen Serverein- 
richtung der Feldgerate (FG1...FGN) abrufbar sind. 



3 . 

35 



Verfahren nach Anspruch 1 oder 2, 

dadurch gekennzeichnet, dass 
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die Basisinf ormationen in einer Speichereinrichtung (50) der 
Proxy- Server einrichtung (1) gespeichert wird. 

4. Verfahren nach einem der vorangehenden Anspruche, 
dadurch gekennzeichnet, dass 
Basisinf ormationen eine jeweilige Alarmstatus information 
fur die Feldgerate (FG1...FGN) umfassen. 

5. Verfahren nach einem der vorangehenden Anspruche, 
dadurch gekennzeichnet, dass 
Basisinf ormationen elektronische Daten zum automatischen 
Erzeugen eines graf isch ausgebbaren Bedienbaums mittels 
der Browsereinrichtung nach dem Ubermitteln der Basisin- 
formation von der Proxy-Servereihrichtung (1) an die Nut- 
zereinrichtung (Nl, NN) umfassen. 

6. Verfahren nach einem der vorangehenden Anspruche, 
dadurch gekennzeichnet, dass 
die Abfrage der Feldgerate (FG1...FGN) durch die Proxy- 
Servereinrichtung (1) zum automatischen Erkennen der an 
die Proxy- Servereinrichtung (1) angeschlossenen Feldgera- 
te (FG1...FGN) mit Hilfe einer „broadcast W -Anf rage ausge- 
fuhrt wird. 

7. Verwendung eines Verfahrens nach einem der Anspruche 1 
bis 6 zur Inbetriebnahme eines Bedien- und Beobachtungs - 
systems fur Feldgerate in energietechnischen Anlagen. 
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